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I.  INTRODUCTION 


A.  BACKGROUND 

The  Naval  Support  Activity  Monterey  Bay  (NSAMB)  manages  the  Department  of 
Defense  (DOD)  Military  Family  Housing  (MFH)  Program  in  the  Monterey,  CA  area. 
Within  the  NSAMB,  the  Assignments  and  Terminations  branch  operates  the  Housing 
Welcome  Center  (HWC),  which  is  the  interface  between  the  organization  and  its 
customers— military  and  government  service  members  (SMs). 

The  ability  of  the  HWC  to  efficiently  store  and  retrieve  information  about  MFH 
and  customers  directly  affects  the  quality  of  service  provided  to  the  customer,  as  well  as 
the  cost  for  the  government  to  provide  housing  services.  Many  times,  moving  out  of  one 
home  and  finding  another  is  the  most  stressful  part  of  a  family  move.  Every  two  or  three 
years,  most  military  and  government  service  families  pack  up  all  of  their  belongings  and 
move  around  the  world  to  a  new  duty  assignment.  Sometimes,  they  live  out  of  their 
suitcases  in  hotels,  with  their  pets  in  a  kennel,  waiting  anxiously  for  the  day  when  they 
can  move  into  a  new  home.  If  the  HWC  does  its  job  correctly,  SM  families  enjoy  a  quick 
transition  to  their  new  homes.  If  the  HWC  fails  to  do  its  job,  the  government  wastes 
money  providing  excessive  temporary  lodging  expenses  while  the  stress  levels  for  SM 
families  grow  larger  by  the  day. 

The  HWC  provides  several  services  to  SM  families.  The  most  routine  service  is 
assigning  SM  families  to  government-owned  quarters,  or  MFH,  and  terminating  the 
assignments  when  they  depart.  However,  not  every  SM  lives  in  MFH  because  it’s  not 
feasible  for  DOD  to  build  and  maintain  quarters  for  everyone.  The  HWC  also  provides  a 
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referral  service  to  help  some  SMs  find  living  accommodations  in  privately  owned 
dwellings. 

Counselors  at  the  HWC  currently  use  the  Family  of  Management  Information 
Systems  (FAMIS)  to  manage  the  MFH  Program.  The  requirements  for  the  MFH 
Program  have  changed  over  the  past  few  years,  prompting  the  Housing  System 
Administrator  to  find  ways  to  modify  FAMIS.  Unfortunately,  FAMIS  is  a  proprietary 
system  which  requires  cooperation  from  the  highest  levels  of  Navy  Housing  and  the 
original  FAMIS  contractor  to  update  the  system.  Since  FAMIS  is  not  a  flexible 
application,  the  HWC  has  created  three  separate  databases  and  added  other  applications, 
such  as  Borland’s  Report  Smith  application  and  Microsoft  Office  Suite,  to  augment 
FAMIS  and  provide  MFH  requirements. 

As  part  of  an  ongoing  effort  to  support  military  agencies  in  the  local  area,  the 
Army’s  Training  Analysis  Center  in  Monterey,  TRAC-Monterey,  supports  the  HWC  with 
forecasting  tools  and  technical  support.  TRAC-Monterey  recently  evaluated  the  current 
MFH  Assignments  and  Terminations  Information  System  and  proposed  a  new  database 
system  that  supports  web-based  input  from  customers  and  provides  more  functionality. 

B.  OBJECTIVES 

The  primary  question  to  be  addressed  by  this  research  is: 

•  What  design  methodology  is  appropriate  for  the  web-based  database 
design  process? 

Secondary  questions  to  be  answered  by  this  research  are: 

•  What  data  quality  issues  need  to  be  addressed  in  a  migration  plan  to  move 
from  the  current  file-based  system  to  implementation  of  an  improved 
database  system? 
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•  How  can  a  relational  database-driven  system  provide  the  Housing 
Welcome  Center  (HWC)  with  user-friendly  views  and  reports,  as  well  as 
flexibility  and  scalability  to  make  facility  management  decisions 
effectively  and  efficiently? 

•  What  decision  support  tool(s)  can  be  used  to  augment  the  database 
application? 

To  highlight  the  benefits  associated  with  modem  database  applications,  we  will 
create  a  relational  database  system  with  connectivity  to  the  HWC  Web  site.  Specifically, 
we  will  develop  a  prototype  Housing  Assignments  and  Terminations  System  (HATS) 
using  Microsoft  Access  and  Internet  Information  Server  (IIS)  to  track  assignments  and 
other  functions,  available  units,  waiting  service  members,  and  housing  utilization.  In 
addition,  we  will  employ  decision  support  tools  to  help  the  housing  office  make  better 
utilization  decisions  and  improve  customer  service. 

C.  SCOPE  AND  METHODOLOGY 

This  thesis  focuses  on  designing  a  new  assignments  and  terminations  system  for 
MFH  in  Monterey,  California.  We  will  provide  a  prototype  database  with  all  of  the 
reports  currently  required  by  the  HWC,  using  real  data  and  web  input  from  the  customer. 
This  thesis  will  not  provide  a  full-scale  implementation  at  the  NSAMB  HWC. 


We  will  use  the  following  systems  analysis  approach  to  develop  the  housing 
assignments  and  terminations  relational  database  prototype: 

•  Requirements  Analysis  -  This  phase  involves  interviews  with  users  and 
analysis  of  the  current  system  to  determine  requirements.  We  will  study 
business  processes,  review  reports  and  forms,  relevant  business  rules,  and 
design  use  cases  to  show  interactions  between  users  and  the  system. 

•  Logical  Database  Design  -  Once  the  requirements  are  understood,  we  will 
use  semantic  object  modeling  to  represent  the  relevant  objects  and  their 
relationships.  To  complete  this  phase,  we  will  convert  the  schema  and 
object  model  into  a  full  relational  schema  implemented  in  Microsoft 
Access. 
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•  Physical  Database  Design  -  The  physical  database  design  requires 
converting  the  logical  database  design  into  normalized  tables  and 
relationships. 

•  Implementation  and  Testing  -  The  database  will  be  implemented  in 
Microsoft  Access.  The  Housing  Web  site  will  connect  to  the  database 
using  Microsoft’s  Open  Database  Connectivity  standard  (ODBC)  and 
Internet  Information  Server  (IIS). 

•  Decision  Support  Tools  Analysis  -  Apply  decision  support  tools  to  the 
database  management  system  using  Access  and  a  Geographic  Information 
System  (GIS). 

D.  ORGANIZATION 

This  thesis  is  organized  as  follows.  Chapter  n  provides  an  overview  of  the 
current  family  housing  assignments  and  terminations  system  at  NSAMB.  It  discusses  the 
original  development  and  the  known  issues  with  the  current  system. 


Chapter  m  proposes  a  reengineered  system  for  housing  assignments  and 
terminations.  It  provides  a  detailed  requirement  analysis,  using  use  cases,  interviews,  and 
process  analysis. 


Chapter  IV  details  the  database  design  and  development  process  of  the  HATS 
prototype  for  the  NSAMB. 

Chapter  V  discusses  data  migration  and  data  quality.  It  explains  the  challenges  of 
cleaning  data,  transferring  it  to  another  system,  and  resolving  data  inconsistencies. 

Chapter  VI  details  the  Graphical  User  Interface  (GUI)  design  and  development 
process.  It  also  discusses  Internet  connectivity  between  the  Web  GUI  and  the  prototype 
database. 
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Chapter  Vn  discusses  the  potential  utility  of  certain  decision  support  tools  in 
housing  policies  and  procedures,  and  how  such  tools  might  be  integrated  with  the  HATS 
prototype. 

Chapter  Vn  provides  a  summary  of  conclusions  and  recommendations  for  further 
development. 
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n.  CURRENT  HOUSING  SYSTEM 


A.  INTRODUCTION 

The  purpose  of  an  HWC  assignments  and  terminations  system  is  to  assist  the 
housing  office  in  providing  housing  to  eligible  Department  of  Defense  (DOD) 
employees.  The  system  also  serves  as  the  automated  database  for  maintaining  records  of 
military  and  privately  owned  housing  facilities,  eligible  service  members  and  dependents, 
and  for  providing  forms  and  reports  to  facilitate  record  keeping.  The  current  information 
management  system  used  by  the  Housing  Office  is  the  Family  Housing  Activity 
Management  Information  System  (FAMIS).  Specifically,  the  assignments  and 
terminations  module  is  named  “Families”. 

Unfortunately,  the  HWC  has  the  Herculean  task  of  knowing  the  real-time  status  of 
thousands  of  houses  and  service  members.  The  HWC  relies  on  FAMIS  to  record 
information  about  such  things  as  the  condition  of  MFH,  the  availability  of  privately 
owned  property,  the  needs  of  the  customer,  and  many  other  important  factors.  In 
addition,  FAMIS  has  to  interact  with  HWC  counselors  to  provide  timely  and  accurate 
information.  The  process  of  assignments  and  terminations  inherently  places  large 
demands  on  FAMIS,  which  was  not  designed  to  keep  pace  with  changing  demands  and 
evolving  technology.  Table  2-1  summarizes  the  HWC’s  customer  and  inventory 
statistics. 
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Service  Members  Supported 

4,500 

Assignments/Terminations  (monthly) 

80 

Customer  Referrals  (monthly) 

50 

Number  of  MFH  Units 

2,200 

Number  of  Referral  Properties 

200-500 

Table  2- 1 .  Customers  and  Inventory  Serviced  by  the  HWC  in  Monterey,  CA 

B.  ASSIGNMENTS  AND  TERMINATIONS  PROCESS 

The  process  of  assigning  and  terminating  quarters  is  simple,  yet  complex,  due  to 
numerous  DoD  housing  regulations. 

In  the  assignment  process,  all  MFHs  are  divided  into  categories,  matching  the 
rank  structure  of  the  military  and  government  service  members  (SMs).  Since  there  are 
normally  more  SMs  than  there  are  available  houses,  each  category  of  MFH  has  a  waiting 
list.  The  date  that  the  SM  departed  his  last  duty  assignment  determines  the  SM’s  position 
on  the  waiting  list.  Whenever  a  MFH  becomes  available,  the  Housing  Office  assigns  the 
next  SM  on  the  waiting  list  to  the  available  MFH. 

In  the  termination  process,  the  SM  files  an  “Intent  to  Vacate”  report  to  housing  as 
soon  as  he  knows  his  moving  date.  The  HMS  schedules  appointments  for  the  HFS  to 
inspect  the  MFH  for  cleanliness  and  suitability  for  the  next  occupant.  Upon  approval 
from  the  HFS,  the  SM  obtains  a  termination  letter  from  the  HMS,  making  the  MFH 
available  for  move-out  maintenance  (and  eventually,  available  for  occupancy). 

This  is  a  simplified  explanation  of  the  assignment  and  termination  processes. 
Usually,  there  are  many  factors,  such  as  medical  conditions,  priority  duty  positions,  and 
other  family  needs  that  complicate  the  process  and  tax  the  information  system. 
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C.  FAMILY  HOUSING  ACTIVITY  MANAGEMENT  INFORMATION 

SYSTEM  (FAMIS) 

Originally  developed  by  Applied  Engineering  Management  (AEM)  Corporation 
in  1985  for  The  Naval  Facilities  Engineering  Command  (NAVFACENGCOM),  FAMIS 
was  designed  to  manage  as  many  Housing  Office  functions  as  possible.  While  the 
FA  MTS  suite  has  many  modules  for  different  housing  functions,  the  “Families”  module 
supports  the  assignments  and  terminations  branch  functions.  The  purpose  of  the 
“Families”  module  of  FAMIS  is  to  assist  housing  managers  throughout  the  Navy  in  their 
efforts  to  supply  military  service  members  and  their  families  both  Navy-owned  and 
private  sector  housing.  For  Navy-owned  housing,  it  supports  wait  list  management, 
assignment  to  and  termination  of  quarters,  occupancy,  and  utilization  reporting  and 
analysis.  For  private  sector  housing,  it  maintains  up-to-date  listings  of  available  rental 
and  sale  properties,  customized  to  the  service  member’s  criteria. 

Over  the  last  sixteen  years,  FAMIS  has  undergone  many  facelifts  in  an  attempt  to 
meet  the  growing  needs  of  housing  offices  and  utilize  advances  in  information  and 
computing  technologies.  The  Navy  admits  that,  as  in  many  civilian  and  government 
software  projects,  FAMIS  project  management  has  been  less  than  perfect.  FAMIS  was 
originally  designed  as  a  disk  operating  system  (DOS)  product.  Due  to  poor  program 
management,  FAMIS  only  captured  about  half  of  the  users’  requirements.  Around  1995, 
HQ  Navy  Housing  decided  not  to  upgrade  FAMIS  to  a  Windows  application  because  the 
newer  GUI  was  not  proven;  however,  the  contractor  eventually  made  the  database 
accessible  through  Microsoft  Windows,  using  a  DOS  GUI  emulation.  At  the  same  time. 
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the  Navy  decided  to  delay  all  major  upgrades  to  FAMIS  and  build  a  new  system  using 
modem  design  methods  (Leidle,  2001). 

Since  there  were  no  planned  upgrades  to  FAMIS,  counselors  at  the  Housing 
Office  asked  for,  and  finally  received,  other  software  to  complement  FAMIS  to  achieve 
their  business  needs.  They  received  Borland’s  Report  Smith  to  improve  the  quality  and 
ease  of  generating  reports.  Later,  they  developed  a  Microsoft  Access  database  because 
the  FAMIS  module  could  not  provide  availability  reports. 

FAMIS  was  originally  designed  as  a  total  housing  solution,  meaning  that  it  was 
intended  to  do  everything  for  everyone  in  the  housing  domain.  Unfortunately,  as  many 
ERP-like  programs  do,  the  application  attempted  to  do  too  much,  and  in  the  process 
failed  to  do  any  individual  module  really  well.  Because  the  application  attempts  to  cover 
all  Housing  Office  functions,  it  contains  over  85  separate  database  files  to  support  the 
main  application. 
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Module  Name 

Module  Function 

Maintenance 

To  manage  housing  maintenance: 
routine  and  emergency  repairs,  planned 
remodeling,  and  move-out  inspections. 
This  module  also  attempted  to  assist 
Facilities  Managers  with  employee  time 
cards,  acquiring  building  supplies,  and 
preparing  bids.  (The  Navy  is  replacing  this 
module  with  the  Maximo  application.) 

Families 

To  assist  housing  in  its  efforts  to 
supply  SMs  and  family  members  either 
Navy  owned  or  private  sector  housing. 

This  module  is  the  primary  focus  of 
my  research. 

Warehouse 

To  manage  the  issue  and  return  of 
warehouse  inventory  items,  such  as 
furniture,  tools,  and  outdoor  equipment. 

Inventory 

To  manage  records  for  MFH  and 
support  facilities  to  be  used  by  the 
Maintenance,  Families,  and  Warehouse 
modules. 

Administration 

To  customize  the  application  for 
each  installation. 

Table  2-2.  FAMIS  Module  Names  and  Functions 

D.  KNOWN  ISSUES 

Although  there  are  many  flaws  with  the  current  system,  the  following  known 
issues  are  the  most  important  to  the  users  of  the  system. 

1.  Poor  User  Interface 

The  FAMIS  menus,  designed  using  text-based  interfaces  over  15  years  ago  for  the 

original  DOS  version,  are  outdated  and  difficult  to  navigate.  In  the  Referral  section, 

users  cannot  modify  property  information  displayed  on  their  monitors  and  they  cannot 

just  click  on  a  modify  button  to  navigate  to  the  modify  screen.  Instead,  they  have  to 
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just  click  on  a  modify  button  to  navigate  to  the  modify  screen.  Instead,  they  have  to 
navigate  back  to  the  main  Referral  menu  and  select  the  modify  function.  In  addition,  if  a 
user  makes  a  mistake  in  the  input/edit  screen,  s/he  cannot  correct  the  error  without 
closing  the  screen  and  navigating  back  to  the  same  screen  to  modify  the 
record. 


Figure  2.  FAMIS  Main  Menu  and  Graphical  User  Interface  (GUI) 

2.  No  Connectivity  with  The  Online  Housing  Application  (DD  Form 
1746) 

Since  most  SMs  use  the  Internet  daily  at  work  and  at  home,  the  Housing  Office 
created  an  online  housing  application  form  to  facilitate  the  application  process. 
Unfortunately,  the  current  system  cannot  communicate  with  the  Web  server,  so  the 
application  information  has  to  be  sent  to  an  HMS  in  text  email  messages.  Once  the  HMS 
receives  the  text  message,  s/he  has  to  re-type  all  of  the  SM’s  information  into  FAMIS. 

3.  Poor  Asset  Visibility  Functions 

Within  several  of  the  functional  areas  of  FAMIS,  users  cannot  complete  actions 

using  FAMIS  alone.  They  have  to  rely  on  patches  and  “work-arounds”  to  do  their 

12 


Microsoft  Access  or  Excel  and  they  have  to  open  Borland’s  Report  Smith  to  conduct 
queries  and  reports.  These  patches  cause  redundancy  and  wasted  time.  For  example, 
when  I  recently  filed  an  “intent  to  vacate”  to  inform  housing  of  my  imminent  move,  the 
HMS  clerk  had  to  open  three  different  applications  (and  three  separate  files)  in  order  to 
tell  the  system  that  my  quarters  are  being  vacated,  and  to  schedule  inspection 
appointments.  Here  are  the  steps  she  performed: 

•  Open  Excel  and  enter  SM  name  and  inspection  dates. 

•  Open  FAMIS  and  enter  the  same  information. 

•  Open  the  Access  “intent  to  vacate”  file  logbook  and  type  the  following:  name, 
date,  address,  floor  plan,  phone  #,  inspection  dates,  and  availability  code. 

Upon  actually  moving  out  of  my  government  house,  the  HMS  will  have  to  open 
the  Access  vacate  file,  copy  the  information  into  Microsoft  Word,  and  type  a  termination 
letter. 

The  Housing  Office  maintains  two  different  Access  logbooks,  one  to  record  when 
a  SM  accepts  MFH — the  “who’s  in  the  house”  file,  and  one  to  record  the  “intent  to 
vacate”  information — ^the  “who’s  leaving”  file.  In  addition,  there  is  no  automated  process 
for  scheduling  the  inspection  appointments. 

4.  Poor  Method  of  Assigning  a  SM  with  an  MFH 

FAMIS  has  no  automated  method  of  making  a  housing  assignment.  The  HMSs 
have  to  print  asset  reports  and  wait  list  reports,  then  compare  them  manually  to  make 
housing  assignments. 

5.  Poor  Reporting  Functionality 

FAMIS  does  not  facilitate  the  creation  of  ad  hoc  reports.  After  implementing 
FAMIS,  the  Navy  noticed  that  it  was  difficult  to  create  queries  and  reports  from  the 
database.  The  Navy’s  solution  was  to  augment  FAMIS  with  Borland’s  Report  Smith,  a 
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commercial  off-the-shelf  (COTS)  visual  database  reporting  and  query  tool.  It  is  not 
convenient  for  users  to  switch  from  FAMIS  to  Report  Smith  to  view  reports  and  query 
the  database. 

6.  Poor  Interoperability  with  Other  Applications 

The  Department  of  the  Navy  Information  Standards  Guidance  (IT-21)  specifies 
the  information  management  environment  for  all  Navy  commands.  The  NSAMB 
Housing  Office  uses  the  Microsoft  Office  in  compliance  with  the  11-21  standard. 
However,  FAMIS  does  not  meet  the  IT-21  standard  because  it  uses  a  text-based  interface 
and  outdated  data  exchange  standards  (which  are  not  compatible  with  MS  Office). 
Because  FAMIS  is  not  compatible  with  MS  Office,  the  HMSs  have  to  retype  information 
from  FAMIS  into  MS  Office  in  order  to  t5q)e  housing  documents. 

E.  UPGRADING  THE  CURRENT  SYSTEM 

Although  the  Navy  Facilities  Command  is  already  fielding  a  replacement  for  the 
current  system,  named  electronic  Family  Housing  (EFH),  FAMIS  was  operational  at  the 
time  of  this  study.  The  Navy’s  housing  management  believes  that  “the  interests  of  the 
Navy  family  housing  community  are  best  served  by  deploying  a  single,  standard  system 
to  all  housing  activities  throughout  the  Navy”  (Harris,  2001,  p.  12). 

F.  SUMMARY 

The  housing  management  system  used  at  NSAMB  is  incomplete,  unreliable, 

burdensome,  and  frustrating  to  use.  The  HWC  counselors  spend  too  much  time 

switching  between  applications  and  files,  resulting  in  transposition  errors  in  data  entry 

and  user  frustration.  Online  housing  applications  are  lost  by  the  system.  In  addition, 

there  are  so  many  patches  to  make  the  current  applications  work,  that  there  is  no  single, 

intuitive  menu  to  meet  their  requirements.  They  need  an  application  that  can  import  their 
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intuitive  menu  to  meet  their  requirements.  They  need  an  application  that  can  import  their 
existing  data,  share  tables  with  an  Internet  server,  display  user-friendly  and  intuitive 
forms  and  reports,  and  identify  critical  information  to  assist  decision  makers.  A  new 
application  can  import  the  existing  data  files  and  spreadsheets  into  a  relational  database 
management  system,  where  users  can  access  the  information  more  effectively  and 
efficiently. 
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m.  PROPOSED  HOUSING  SYSTEM 


A.  INTRODUCTION 

In  order  to  elicit  requirements  for  the  new  system,  we  have  chosen  to  use  the 
Knowledge  Analysis  of  Tasks  (KAT)  method  as  an  aide.  KAT  is  an  object-oriented  task 
analysis  method  proposed  by  Peter  Johnson.  While  KAT  is  not  a  requirements  elicitation 
method  per  se,  it  provides  a  process  to  help  describe  the  domain,  understand  the  objects 
and  interactions,  and  construct  a  model  of  the  housing  assignment  and  termination 
process.  KAT  is  a  method: 

...concerned  with  collecting  data  from  variety  of  sources  (e.g.,  protocol 
analysis,  standard  procedures,  textbooks,  interviews),  analyzing  these  data 
to  identify  individual  elements  involved  in  the  task  (e.g.,  objects,  actions, 
procedures,  goals,  and  subgoals),  and  constructing  a  model  of  the  overall 
knowledge  used  by  people  accomplishing  the  task  of  interest  (Bruegge, 

2000,  p.  120). 

KAT  differs  from  the  Unified  Modeling  Language  (UML)  in  two  ways:  what  is 
does  and  when  it  is  done.  KAT  is  a  knowledge  analysis  method  that  provides  a  process 
for  requirements  elicitation,  while  UML  is  a  modeling  language,  and  not  a  method 
(Fowler,  1997,  p.  43).  Second,  KAT  occurs  before  we  apply  UML.  Software  designers 
apply  KAT  in  the  requirements  elicitation  phase  prior  to  using  UML  in  the  requirements 
elaboration  phase.  We  will  apply  the  KAT  methodology  in  order  to  understand  the 
requirements  before  using  UML  diagrams  to  express  the  requirements. 

In  order  to  analyze  the  tasks  involved  in  the  assignment  and  termination  process, 
we  collected  information  from  various  sources.  First,  we  interviewed  several  Housing 
Office  counselors,  including  the  division  supervisor,  and  users  of  FAMIS  in  other 


divisions  of  housing,  such  as  maintenance  and  facilities.  We  asked  the  users  to  describe 
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problems  with  the  current  system,  as  well  as  useful  features  and  capabilities  of  the 
system.  In  some  cases,  we  went  through  actual  scenarios  in  which  the  current  system 
fails  to  support  housing  needs,  and  discussed  possible  solutions. 


Define  Use  Cases 


I 


Document  the  Requirements 


Vision, 

Commitment, 
Existing  Applications 


Interview  Users 


Requirements 
Document  & 
Project  Scope 


Figure  3-1 .  Sources  of  Information  for  Requirements  Gathering  (After  Ambler,  2000, 

p.67) 

Another  source  of  information  is  personal  experiences  with  the  assignment  and 
termination  process.  I  have  lived  in  government  quarters  twice  and  have  received  referral 
services  more  than  a  few  times.  During  the  course  of  this  thesis,  I  arranged  an 
assignment  for  a  friend  and  paid  particular  attention  to  the  information  requirements  and 
interactions  with  the  occupant,  the  counselor,  and  the  system.  I  recently  filed  my  own 
“intent  to  vacate”  and  personally  experienced  the  shortcomings  of  the  current  system. 

Other  sources  of  information  to  determine  requirements  include  the  current 
system  and  documentation,  as  well  as  the  NSAMB  housing  regulations.  The  current 
system  acts  as  a  prototype  because  it  allows  users  to  interact  with  the  system  and 
provides  feedback  for  making  improvements.  The  current  system  documentation 
contains  a  data  dictionary  and  helps  explain  the  functionality.  Finally,  the  NSAMB 
housing  regulations  provide  the  key  business  mles  and  constraints  that  shape  the  use 
cases,  and  ultimately,  the  requirements. 
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B.  FUNCTIONAL  REQUIREMENTS  FOR  THE  HOUSING  ASSIGNMENTS 

AND  TERMINATIONS  SYSTEM  (HATS). 

In  order  to  determine  the  functional  requirements  for  the  new  system,  named  the 
Housing  Assignment  and  Terminations  System  (HATS),  we  analyzed  the  assignment  and 
termination  process  from  the  various  sources,  deduced  the  required  functions,  created  a 
functional  decomposition,  and  captured  the  use  cases  to  refine  the  requirements. 

HATS  is  a  computer  information  system  that  assigns  eligible  DoD  employees  to 
military  family  housing  and  provides  off-base  referrals.  The  system  allows  users  to  enter 
data,  modify  existing  records  of  occupants  and  housing  units,  view  and  print  reports  and 
DOD  forms,  and  use  decision  support  tools  to  help  management  make  better  decisions. 

HATS  consists  of  a  database  server  and  client  terminals  running  a  database 
application.  HATS  is  also  accessible  to  users  through  an  Internet  browser.  The  main 
Internet  feature  is  to  allow  incoming  service  members  to  apply  for  housing  (and  enter 
their  information  directly  into  the  database,  without  the  assistance  of  an  HMS).  Another 
Internet  feature  is  to  allow  incoming  service  members  to  view  and  print  the  waiting  list. 
Internet  users  can  only  view  the  reports — ^they  cannot  modify  or  delete  files. 

With  slight  modification,  HATS  can  be  used  at  any  U.S.  DOD  housing  office  in 
the  world. 

C.  NONFUNCTIONAL  REQUIREMENTS 

Some  requirements  are  important  to  the  look,  feel,  and  performance  of  the  system, 
but  they  don’t  provide  any  additional  functionality  to  the  system. 
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1.  Ease  of  Use 


The  system  must  be  easy  to  navigate  between  functions  and  it  must  use  drop 
down  menus  whenever  possible.  The  GUI  should  be  appealing  and  navigation  through 
the  menus  should  be  easily  accomplished  with  either  a  keyboard  or  a  mouse.  Users 
should  not  reach  dead  end  screens;  instead,  they  should  be  a  mouse  click  or  two  away 
from  important  functions.  The  design  should  be  similar  to  popular,  useful  Web  sites  that 
offer  easy  navigation. 

2.  Scalability 

The  NSAMB  HWC  only  services  about  5,000  customers  currently;  however,  it’s 
possible  that  DOD  could  increase  the  number  of  service  members  in  the  area.  In 
addition,  it  would  be  an  added  benefit  to  DOD  to  be  able  to  use  the  NSAMB  HATS  for 
another  military  installation  that  has  over  10,000  customers.  In  both  cases,  the  system 
should  be  able  to  handle  the  increase  of  records  without  suffering  performance  shortfalls. 

3.  Availability 

The  system  has  to  be  available  24  hours  a  day,  7  days  a  week  because  the 

customers  live  in  nearly  every  time  zone. 

4.  Responsiveness 

We  personally  observed  a  task  at  the  HWC  that  took  over  45  seconds  using  the 
current  system.  The  proposed  system  should  respond  to  requests  in  less  than  15  seconds. 

D.  PSEUDO  REQUIREMENTS 

1.  Documentation 

The  Housing  Office  requires  a  user’s  manual  to  explain  the  system’s  details,  such 
as  a  menu  summary,  valid  field  options,  and  a  glossary. 
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2. 


Hardware  and  Software  Considerations 


The  system  must  be  compatible  with  IT-21  hardware  and  software.  Specifically, 
the  TRAC-Monterey  requires  that  the  system  be  designed  using  a  Microsoft  Access 
database,  since  the  software  is  already  required  by  Navy  Housing  Offices  around  the 
world.  In  addition,  the  system  must  interface  with  the  Housing  Office’s  Web  server, 
which  runs  Microsoft’s  Internet  Information  Server  (IIS)  software. 

3.  Error  Handling  and  Extreme  Conditions 

When  encountered,  the  system  should  gracefully  notify  the  user  of  errors  or  other 

adverse  conditions  and  offer  a  solution.  Whenever  possible,  the  forms  and  menus  should 
only  offer  valid  input  ranges  to  avoid  errors. 

4.  Physical  Environment 

The  system  has  to  operate  within  the  constraints  of  the  current  physical 
environment,  meaning  that  it  has  to  work  with  the  existing  hardware  and  software  at  the 
Housing  Office. 

5.  Security  Issues 

The  system  must  enforce  access  control  using  user  identification  and  passwords. 
Once  the  system  allows  access  to  users,  there  is  no  need  for  further  compartmentalized 
security.  The  system  interface  with  the  Web  server  is  particularly  vulnerable  to 
unauthorized  access  and  malicious  activity. 

6.  Resource  Issues 

Because  there  will  be  as  many  as  20  concurrent  users  on  the  system,  it  must 
resolve  competing  reads  and  writes  to  the  database.  The  system  has  to  either  lock 
records,  or  specific  tables,  to  ensure  data  consistency  and  to  avoid  deadlock. 
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E.  SYSTEM  MODELS 


1.  Functional  Decomposition 

The  functional  decomposition  is  a  process  that  starts  with  defining  the  top-level 
system  functions,  each  of  which  is  further  refined  in  iterative  steps.  The  end  result  is 
bottom-level  functions  that  are  easily  captured  in  pseudo  code  and  eventually 
programmed  in  a  computer  language  or  using  an  application  development  suite,  such  as 
Microsoft  Access. 

2.  Use  Case  Model 

Use  cases  are  primary  elements  in  object  oriented  software  development.  Using 
the  requirements  derived  from  the  functional  decomposition  and  the  KAT,  combined  with 
the  functions  of  the  current  system  and  user  feedback,  we  developed  21  use  cases  that 
describe  the  interaction  between  the  users  and  the  system.  For  each  use  case,  we  used  a 
common  template,  shown  in  Table  3-1,  that  includes  12  sections. 

Using  the  template  shown  in  Table  3-1,  we  used  an  iterative  process  to  complete 
the  template  for  each  of  the  21  use  cases,  which  are  summarized  in  Table  3-2  and  listed  in 
entirety  in  Appendix  A. 
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Figure  3-2.  Top-level  Functions  of  the  Proposed  System 
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Figure  3-3.  Decomposed  Second  Level  Functions 


25 


UC5 

Apply  Online 

The  SM  visits  the  NSAMB  Housing  Web  site. 
S/he  fills  out  the  DD  Form  1746,  Application 
For  Assignment  To  Housing,  by  entering 
personal  information  in  the  required  fields  of 
the  Web  page. 

UC  10 

Apply  For  Housing 

The  SM  applies  for  housing  in  person,  or 
through  the  mail.  She  fills  out  the  DD  Form 
1746,  Application  For  Assignment  To 
Housing,  and  gives  a  hard  copy  to  the  HMS. 

UC  15 

Modify  SM 

The  HMS  may  need  to  correct  inaccurate  or 
outdated  SM  information  such  as  number  of 
dependents  or  an  incorrect  SSN. 

UC20 

View  and  Print 
Waiting  Lists 

The  Housing  Office  constantly  views  the 
waiting  list  to  update  SMs  on  their  place  on 
the  list  and  their  expected  availability  date. 
The  HMS’s  also  print  periodic  lists  to  display 
in  the  Housing  lobby. 

UC25 

Move  SM  to  Actual 
Waiting  List 

The  SM  gives  the  HMS  verification  of 
dependents,  orders,  and  departure  from  last 
assignment.  With  this  information,  the  HMS 
is  authorized  to  move  the  SM  to  the  actual 
waiting  list. 

UC30 

Promote  SM 

The  SM  receives  a  promotion  since  she 
entered  the  expected  waiting  list,  making  her 
eligible  for  a  higher  category  of  housing.  The 
HMS  moves  the  SM  to  the  new  actual  waiting 
list. 

UC35 

Delete  SM  From 
Waiting  List 

A  SM  is  on  either  the  expected  or  actual 
waiting  list,  but  has  decided  to  live  off  base. 

UC40 

Maintain  Freeze 

Zone 

Housing  stabilizes  the  position  of  the  top  ten 
percent  of  SMs  on  each  actual  waiting  list  by 
not  placing  new  arrivals  in  the  freeze  zone, 
regardless  of  rank,  duty  assignment,  or 
detachment  date.  They  make  exceptions  for 
key  and  essential  SMs,  based  on  specific 
guidance.  When  this  happens.  Housing  places 
these  SMs  at  the  top  of  the  freeze  zone, 
without  displacing  SMs  with  a  housing  offer. 

UC45 

Offer  Housing 

The  HMS  notifies  a  SM  that  her  sequence 
number  is  next  on  the  actual  waiting  list.  The 
system  finds  three  houses  matching  the  SM’s 
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category  and  the  HMS  offers  the  SM  to 
choose  one  house  to  live  in  (after  visual 
inspection). 

UC  50  Make  Assignment  The  SM  chooses  to  occupy  one  of  the  houses 

offered  by  the  HMS,  who  makes  the  official 
assignment  (matching  the  SM  with  a  housing 
address). 

UC55  Terminate  SMs  frequently  receive  orders  to  move  to 

Assignment  other  duty  stations.  Once  a  SM  has  orders, 

she  completes  an  “Intent  to  Vacate”  letter  and 
informs  the  HMS  of  the  specific  dates. 
Eventually,  the  SM  moves  and  terminates  the 
housing  assignment. 

UC60  Prepare  CRL  An  incoming  SM  wants  information  on  off- 

base  housing.  The  SM  gives  the  HMS  search 
criteria  for  desired  living  arrangements.  The 
HMS  enters  the  information  into  HATS  and 
prints  a  Customer  Referral  List  for  the  SM. 

UC  65  Add  or  Edit  MFH  Occasionally,  the  HMS  needs  to  edit  the 

description  of  MFH  to  reflect  upgrades  or 
modifications.  In  the  event  of  new 
construction,  this  is  the  use  case  used  to  add 
the  address  to  the  inventory. 

UC  70  Add  or  Edit  Private  Details  about  off  base  rental  property  change 

Property  almost  daily.  The  HMS  needs  to  add  new 

rental  property  to  the  system  and  change 
descriptions  and  terms  to  existing  properties. 

UC  75  Delete  Address  For  one  reason  or  another,  the  HMS  needs  to 

remove  either  government  or  privately-owned 
property.  For  example,  the  owner  of  an  off 
base  property  decides  to  sell  and  no  longer 
offer  it  for  rent.  Or  in  the  case  of  the 
government  quarters,  the  base  sells  the 
property  to  another  entity. 

UC  80  Add  or  Edit  Owner  The  HMS  adds  or  edits  information  about  an 

or  Manager  owner  or  property  manager.  This  can  happen 

due  to  a  sale,  or  when  a  new  manager  takes 
over  the  property. 

UC  85  Change  Availability  When  a  specific  house  is  unavailable  to  SMs, 

the  HFS  has  to  provide  a  date  when  she  thinks 
the  unit  will  be  ready  for  occupancy.  Once 
move-out  or  other  maintenance  is  complete, 

_ the  HFS  notifies  the  system  that  the  MTO  is 
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fit  for  a  new  occupant. 

UC90 

View  and  Print 
Reports 

There  are  over  20  reports  that  users  request 
from  the  system  on  any  given  day.  The  HMS 
or  HFS  can  use  the  “Queries  &  Reports” 
function  of  HATS  or  s/he  can  use  menus  in 
the  other  functions  to  view  and  print  reports. 

UC95 

Manage  Accounts 

Employees  come  and  go,  get  promoted,  or 
change  positions  at  the  Housing  Office, 
requiring  changes  to  user  access  to  the 
system. 

UC  100 

Maintain  Database 

The  HBDA  needs  to  maintain  the  database  in 
the  system  occasionally.  S/he  may  need  to 
change  forms,  reports,  or  other  internal  files  in 
order  to  maintain  the  system.  Also,  Housing 
does  not  want  another  user  inadvertently 
changing  the  database  structure  and 
corrupting  the  system. 

UC105 

Authenticate  User 

All  users  who  request  entry  to  the  system 
must  prove  they  are  who  they  say  they  are 
(authentication).  This  applies  to  users  inside 
Housing  as  well  as  outside.  Who  the  users  are 
determines  what  they  have  access  to 
(authorization). 

Table  3-2.  Summary  of  Use  Cases 


A  use  case  diagram  is  an  essential  requirement  in  the  UML.  It  helps  system 
designers  visualize  the  use  cases  and  understand  the  scope  of  the  system.  Figure  3-4 
depicts  the  UML  use  case  diagram  for  the  proposed  system. 


Figure  3-4.  HATS  Use  Case  Diagram 


F.  SUMMARY 

Defining  requirements  is  a  critical  step  in  designing  information  systems.  Too 
many  times,  system  engineers  make  mistakes  in  the  requirements  analysis  phase  that  cost 
the  project  time,  money,  and  sometimes,  critical  functionality.  The  Knowledge  Analysis 
of  Tasks  (KAT)  method  helps  describe  the  problem  domain  and  objects  and  interactions. 
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Using  the  KAT  methodology,  we  analyzed  various  sources  of  information  before 
determining  the  system  requirements  and  expressing  them  using  a  UML  diagram.  The 
functional  decomposition  and  use  cases  were  the  most  useful  tools  for  determining 
requirements  for  the  Housing  Assignments  and  Terminations  System  (HATS). 
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IV.  HOUSING  SYSTEM  PROTOTYPE  DESIGN 


A.  OVERVIEW 

After  determining  the  requirements  for  the  Housing  Assignments  and 
Terminations  System,  we  can  begin  the  design  phase  of  our  HATS  prototype.  The 
importance  of  this  phase  cannot  be  overstated.  Mistakes  in  design  will  most  likely 
cascade  into  all  subsequent  phases,  with  potential  serious  effects  upon  database 
performance.  We  start  with  a  logical  design,  using  a  standard  database  modeling 
application.  Next,  we  transform  the  model  into  a  physical  design  of  the  database.  Once 
our  design  is  complete,  we  will  must  extract  the  data  from  the  HWC’s  legacy  system 
(FAMIS)  and  Access  database,  and  fit  the  data  with  our  schema. 

B.  LOGIGAL  DATABASE  DESIGN 

In  our  requirements  analysis,  we  identified  use  cases  that  depict  interaction 
between  users  and  the  system.  As  described  in  the  use  cases,  the  users  typically  create, 
replace,  update,  or  delete  information  in  order  to  complete  forms  and  create  reports  about 
service  members,  houses,  referral  property,  and  other  entities  in  their  environment.  We 
decided  to  model  these  entities,  also  known  as  objects  or  semantic  objects,  using  the 
semantic  object  model  (SOM)  shown  in  Figure  4-1. 

A  semantic  object  is  a  “named  collection  of  attributes  that  sufficiently  describes  a 
distinct  identity”  (Kroenke,  2000,  p.  74).  A  service  member  is  an  example  of  a  semantic 
object  because  it  describes  a  distinct  identity  that  we  wish  to  track  and  report.  An 
attribute  of  an  object  is  a  characteristic  that  describes  the  object  in  more  detail.  For 
example,  the  attribute  “LastName”  describes  the  object  SERVICEMEMBER. 
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The  first  object  shown  in  Figure  4-1  is  the  housing  customer,  the 
SER VICEMEMBER.  The  unique  identifier  for  each  service  member  is  his  or  her  social 
security  number  (SSN).  Each  service  member  in  our  model  has  one-and-only-one  of  the 
following  attributes:  FullName,  Paygrade,  BranchOfService,  Rank,  DateOfRank,  PRD, 
NumberOfFamilyMembers,  Command,  Priority,  and  ControlDate.  A  service  member 
may  have  zero-to-one  of  the  following:  HomePhone,  WorkPhone,  SpouseWorkPhone, 
Email,  WaitStatus,  BedroomsRequested,  BedroomsAuthorized,  Pets,  Weapons,  Medical, 
Date  Renewed,  and  DeferMFHUntilDate.  If  a  service  member  has  a  WaitStatus,  s/he 
must  have  one-and-only-one  of  the  following:  WATTINGLIST,  SequenceNumber,  and 
InFreezeZone.  A  service  member  may  have  zero-to-many  FAMILYMEMBERs  and 
ASSIGNMENTS.  Because  the  SERVICEMEMBER  object  is  related  to  other  objects, 
such  as  FAMILYMEMBER,  the  model  has  to  capture  the  appropriate  relationships  in 
order  to  have  any  meaning.  In  Figure  4-1,  related  objects  are  enclosed  in  rectangles  with 
their  associated  cardinalities  appearing  to  the  right.  APPENDIX  B  contains  a  description 
of  each  of  the  remaining  objects  and  their  relationships. 

C.  PHYSICAL  DATABASE  DESIGN 

Although  data  modeling  is  an  important  task  in  database  development,  a  model  by 
itself  is  only  a  means  to  an  end.  We  have  to  transform  the  semantic  object  model  into 
relational  tables  in  a  database  which  will  be  used  to  use  the  data  in  a  meaningful  way. 
We  will  use  a  three-step  process  to  transform  the  SOM  into  a  relational  database  design: 

•  Transform  the  SOM  into  Relations 

•  Normalize  Relations 

•  Create  the  Database  Schema 
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Once  the  model  is  transformed  into  a  relational  database  design,  we  can  migrate 
the  data  from  the  current  system  into  the  proposed  system  and  focus  on  fulfilling  the 
requirements  for  the  system. 

1.  Transforming  the  SOM  into  Relations 

We  follow  algorithms  proposed  by  Kroenke  (2000,  pp.  169-185)  for  transforming 
the  semantic  objects  into  relations,  or  tables.  The  SER VICEMEMBER  object,  shown  in 
Figure  4-2,  serves  as  an  example  of  implementing  transformation  algorithms.  The  first 
step  is  to  determine  the  type  of  object.  In  this  case,  SERVICEMEMBER  is  a  hybrid 
object  because  it  contains  at  least  one  multi-valued  group  attribute  (WaitStatus)  that 
includes  an  object  attribute  (WAITINGLIST).  The  recommended  approach  for  this  type 
of  object  is  to  apply  a  combination  of  techniques  for  composite  and  compound  objects.  A 
composite  object  is  an  object  that  contains  one  or  more  multi-valued,  non-object 
attributes.  A  compound  object  contains  at  least  one  object  attribute. 

The  next  step  is  to  create  a  relation  for  SERVICEMEMBER  and  both  of  the 
contained  objects  FAMILYMEMBER  and  ASSIGNMENT.  The  primary  key  for  the 
SERVICEMEMBER  table  is  the  social  security  number  (SSN)  attribute.  Since  a  service 
member  may  have  many  family  members,  the  primary  key  for  the  FAMILYMEMBER 
table  consists  of  the  two  attributes:  the  foreign  key  attribute  SSN  (from 
SERVICEMEMBER),  and  the  RelationCode  attribute,  which  specifies  a  unique  relation 
within  a  particular  family.  The  ASSIGNMENT  table  primary  key  consists  of  two  foreign 
keys  and  one  local  key:  SSN  (SERVICEMEMBER),  UnitID  (MFHUNIT),  and 
AssignmentDate.  Since  a  service  member  can  have  zero-to-many  family  members,  we 
place  the  key  of  the  SERVICEMEMBER  table  (SSN)  as  a  foreign  key  attribute  in  the 
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FAMILYMEMBER  table.  In  this  case,  the  foreign  key  becomes  part  of  the  primary  key 
of  the  FAMILYMEMBER  table  because  a  FAMILYMEMBER  instance  will  be  related  to 
one  and  only  one  SERVICEMEMBER  instance.  Similarly,  the  ASSIGNMENT  object 
associates  a  service  member  with  a  house  (MFHUNIT),  so  it  too  is  a  special  case  of  a 
compound  object  known  as  an  association  object.  In  this  case,  we  again  place  the  key 
(SSN)  for  SERVICEMEMBER  as  a  foreign  key  in  the  ASSIGNMENT  relation.  As  with 
the  FAMILYMEMBER,  this  foreign  key  also  serves  as  part  of  the  primary  key  for  the 
ASSIGNMENT  table.  No  attributes  of  FAMILYMEMBER  or  ASSIGNMENT  are 
placed  in  the  SERVICEMEMBER  relation. 

Next,  we  apply  the  technique  for  composite  objects  to  transform  the  multi-value 
group,  WaitStatus.  Since  this  group  contains  another  object,  WAITINGLIST,  we 
establish  a  relation  for  WAITINGLIST.  Because  a  WAITINGLIST  can  have  many 
service  members  awaiting  housing,  we  place  the  keys  of  WAITINGLIST  (Designation 
and  BaseName)  in  the  SERVICEMEMBER  relation  as  foreign  keys.  Finally,  we  create  a 
relation  for  the  group  identifier,  WaitStatus.  Since  the  relationship  between  the  new 
relation  WAITSTATUS  and  SERVICEMEMBER  is  one-to-one,  we  place  the  key  of  one 
relation  into  the  other  as  a  foreign  key.  Now,  all  composite  and  compound  objects  are 
transformed  into  the  relations,  leaving  only  simple  attributes. 

The  final  step  in  transforming  the  SERVICEMEMBER  object  is  representing  the 
simple  attributes,  such  as  Paygrade,  BranchOfService,  and  others  shown  in  Figure  4-2. 
We  then  place  the  simple  attributes  in  the  SERVICEMEMBER  relation  and  the  table 
design,  shown  in  Table  4-1,  is  complete. 
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Figure  4-2.  SERVICEMEMBER,  ASSIGNMENT,  WAITINGLIST,  and 

FAMILYMEMBER  Objects 
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Relation 

Attributes 

SERVICEMEMBER 

(SSN,  LastName,  FirstName,  MI,  Pay  grade, 

BranchOfService,  Rank,  DateOfRank,  PRD, 

NumberOfFamilyMembers,  Command,  Priority,  HomePhone, 

WorkPhone,  SpouseWorkPhone,  Email,  ControlDate, 

BedroomsRequested,  Bedrooms  Authorized, 

DeferMFHUntilDate,  Pets,  Weapons,  Medical,  Remarks, 

Designation_FK,  BaseName_FK) 

T able  4- 1 .  Transformed  SER VICEMEMBER  Relation 


We  continued  the  transformation  process  by  applying  Kroenke’s  algorithms  to  the 
remaining  semantic  objects  in  Figure  4-1.  Appendix  C  shows  all  of  the  transformed 
relations. 

2.  Normalization 

Once  we  have  established  our  relations,  we  need  to  normalize  any  undesirable 
relations  to  avoid  modification  anomalies,  which  are  unwanted  consequences  in  our 
relations.  The  purpose  of  normalizing  our  relations  is  to  obtain  a  refined  relational  model 
that  performs  according  to  our  design. 

A  normal  form  defines  a  class  of  relations  “and  the  techniques  for  preventing 
anomalies”  (Kroenke,  2000,  p.  1 19).  Depending  on  a  relation’s  stmcture,  it  can  be  in  one 
of  six  normal  forms:  first,  second,  third,  Boyce-Codd,  fourth,  and  fifth. 
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All  of  the  tables  of  data  in  Appendix  C  are  in  first  normal  form  because  they  meet 
the  following  conditions: 

•  All  cells  of  the  table  are  of  a  single  value; 

•  All  attributes  are  of  the  same  kind; 

•  Each  column  has  a  unique  name; 

•  No  two  rows  are  identical. 

In  order  to  be  in  second  normal  form,  all  non-key  attributes  must  depend  on  the 
entire  key.  For  relations  with  a  single  attribute  as  key,  they  are  automatically  in  second 
normal  form.  Several  of  our  relations  meet  this  requirement  because  they  have  a  single 
attribute  as  the  key:  MFHUNIT,  FLOORPLANCODE,  APPLIANCE,  BASE, 
ZIPCODE,  NEIGHBORHOOD,  PRIVATERENTALPROPERTY,  OWNER, 
SYSTEMUSER,  HMS,  HFS,  and  SYSTEMADMINISTRATOR.  All  of  the  relations 
with  multiple  attribute  keys  are  in  second  form  because  the  non-key  attributes  are  about 
the  entire  key,  not  just  part  of  the  key. 

A  relation  is  in  the  third  normal  form  if  it  is  in  already  in  second  normal  form  and 
its  attributes  are  about  just  the  key,  not  about  the  key  and  another  non-key  attribute.  Even 
when  a  relation  is  in  the  second  normal  form,  we  can  still  experience  modification 
anomalies.  One  kind  of  modification  anomaly  that  we  want  to  avoid  is  a  deletion 
anomaly.  A  deletion  anomaly  occurs  when  we  delete  facts  about  one  entity  and 
inadvertently  delete  facts  about  a  separate  entity  (Kroenke,  2000,  p.  118).  For  example, 
in  the  SER VICEMEMBER  relation,  a  service  member,  like  John  Doe,  has  an  SSN  (123- 
45-6789),  a  Paygrade  (06),  and  a  Rank  (colonel).  In  addition,  assume  that  John  Doe  is 
the  only  instance  of  SERVICEMEMBER  with  the  rank  of  colonel  in  the  relations.  If  we 
delete  John  Doe’s  record  from  our  database,  we  also  inadvertently  delete  the  fact  that  a 
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service  member  in  the  Paygrade  of  06  has  the  rank  of  colonel.  The  solution  to  this 
anomaly  is  to  create  two  separate  relations,  such  as  the  ones  shown  in  Table  4-2.  Now, 
the  SER VICEMEMBER  relation  is  in  the  third  normal  form. 


Relation 

Attributes 

SERVICEMEMBER 

(SSN,  LastName,  FirstName,  MI,  Paygrade,  BranchOfService, 
DateOfRank,  PRD,  NumberOfFamilyMembers,  Command, 
Priority,  HomePhone,  WorkPhone,  SpouseWorkPhone,  Email, 
BedroomsRequested,  BedroomsAuthorized,  DeferUntilDate, 
ControlDate,  Pets,  Weapons,  Medical,  Remarks, 

Designation_FK,  BaseName_FK) 

RANK 

(Pavsrade,  Rank) 

Table  4-2.  Creating  Two  Separate  Tables  to  Avoid  Deletion  Anomalies 


Since  this  prototype  is  not  intended  for  full  implementation  at  the  HWC,  we  feel 
that  normalizing  the  relations  to  the  third  normal  form  is  sufficient  for  this  purpose.  All 
tables  in  Appendix  C  now  satisfy  3'^'’  normal  form,  and  are  ready  to  be  put  into  the 
database  schema. 

3.  Creating  the  Database  Schema 

The  schema  defines  the  database’s  structure,  tables,  relationships,  domains  and 
business  rules  (Kroenke,  2000,  p.  30).  We  formalized  part  of  the  schema  when  we 
created  the  semantic  object  model  using  the  Cybeiprise  Tools  DBApp  Developer  2.5 
Standard  Edition  (by  Wall  Data,  Inc.).  As  we  defined  the  objects,  we  also  defined  the 
attribute  domains.  We  then  used  the  “Create  Database”  tool  in  DBApp  to  create  our 
initial  MS  Access  database,  complete  with  the  tables  and  data  definitions  that  are  part  of 
our  schema.  After  translating  the  schema  into  Access,  the  database  is  now  ready  to 
receive  the  HWC’s  operational  data. 
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D.  SUMMARY 


The  design  phase  of  our  HATS  prototype  started  with  an  understanding  of  the 
requirements.  We  created  a  semantic  object  model  to  represent  our  proposed  system. 
Using  DBApp,  we  captured  the  foundation  of  the  schema  in  our  SOM.  Then,  using  a 
three-step  process,  we  transformed  the  object  model  into  a  physical  design,  represented 
by  our  relational  model.  Now  that  our  design  phase  is  complete,  we  need  to  extract  the 
pertinent  data  from  the  HWC’s  systems,  clean  it,  and  merge  it  into  our  Access  tables. 
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V.  DATA  MIGRATION 


A.  INTRODUCTION 

Migrating  data  from  one  system  to  another  sounds  like  a  simple  task;  however,  it 
can  be  a  difficult  process  for  several  reasons.  First,  the  people  performing  the  migration 
have  to  thoroughly  understand  the  existing  database  schema;  otherwise,  they  may  commit 
errors  that  have  detrimental  consequences  when  applied  to  the  new  system.  In  many 
cases,  the  original  design  team  is  not  part  of  the  migration,  which  may  occur  well  after 
the  initial  system  was  built.  In  our  case,  15  years  elapsed  since  the  original  system  was 
implemented  and  no  one  from  the  original  design  team  was  available.  Second,  the 
existing  schema  may  not  match  the  newly  designed  schema.  In  our  case,  the  HWC  uses 
many  flat  files,  with  data  definitions  that  are  not  consistent  with  current  “best  practices”. 
In  order  to  convert  the  flat  files,  we  may  have  to  perform  detailed  data  manipulation,  eind 
in  the  worst  case,  re-enter  some  of  the  data  to  conform  to  our  design.  Finally,  the  people 
performing  the  data  migration  have  to  understand  the  business  process,  rules,  and 
constraints  that  were  in  place  during  the  design  and  implementation  of  the  legacy 
database  as  well  as  those  currently  in  use  by  the  organization. 

Planning  a  migration  for  the  HWC’s  data  is  further  complicated  because  of  the 

recent  history  of  its  military  customer  in  the  Monterey  Bay  area.  Over  the  past  10  years, 

the  HWC  has  recorded  information  about  the  housing  areas  in  several  tables,  using 

different  aliases,  and  creating  inconsistencies  in  the  database.  For  example,  in  one  table, 

the  neighborhood  describing  a  particular  unit  appears  as  POM,  while  the  same  field  is 

called  PA  in  another  table.  This  confusion  is  partially  a  result  of  a  U.S.  Defense 

Department  program,  known  as  Base  Realignment  and  Closure  (BRAC),  designed  to  cut 
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military  infrastructure  costs  by  closing  American  bases  around  the  world.  Today,  the 
RTWC  serves  the  entire  military  community  in  Monterey.  However,  just  ten  years  ago, 
the  Army’s  former  Housing  Office  at  Fort  Ord  managed  over  half  of  the  current  housing 
inventory.  The  NSAMB  assumed  the  responsibility  to  manage  military  housing  at  the 
Presidio  of  Monterey  (also  formerly  managed  by  the  Army)  and  Fort  Ord.  Both  former 
Army  housing  areas  are  defined  using  multiple  naming  conventions  in  both  the  FAMIS 
and  Access  tables.  Over  the  years,  Fort  Ord’s  name  has  changed  several  times.  For  a 
few  years,  it  was  known  as  the  Presidio  of  Monterey  Annex,  abbreviated  as  PA,  or 
POMANNEX.  Recently,  it  was  renamed  Ord  Military  Community  (OMC).  In  addition, 
the  Presidio  of  Monterey,  abbreviated  POM,  also  goes  by  the  name  DLI,  which  is  short 
for  the  major  command  stationed  at  the  Presidio,  the  Defense  Language  Institute.  Our 
relational  prototype  must  raise  the  level  of  data  integrity  and  allow  instant,  cascading 
updates  of  such  information  with  few  keystrokes. 

B.  DATA  EXTRACTION  AND  MIGRATION 

1.  Overview 

The  HWC  provided  access  to  all  their  database  files,  including  the  FAMIS  legacy 
database  files  and  their  MS  Access  database  files.  We  reviewed  the  tables  and  talked  to 
the  HWC  database  administrator  to  make  sure  that  we  understood  the  schema  and  its  link 
to  their  business  process.  Then,  we  analyzed  the  existing  tables  and  performed  a  data 
crosswalk,  as  shown  below  in  the  SERVICEMEMBER  table  migration  (Table  5-1),  for 
each  of  our  relations,  matching  the  existing  schema  with  our  prototype  schema  whenever 
possible.  In  some  cases,  the  table  attributes  matched  and  we  only  needed  to  import  the 
files  using  the  MS  Access  menus.  In  the  majority  of  cases,  however,  the  tables  were 
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either  partially  matching,  or  not  matching  at  all.  Making  matters  worse,  the  HWC’s 
Access  database  did  not  have  primary  keys  for  the  tables  and  the  relations  were  not 
linked  or  related  at  all.  Thus,  we  had  to  deal  with  flat  files,  many  of  which  we  could  not 
directly  link  to  the  other  tables  in  FAMIS,  which  contained  most  of  the  operational  data. 
Many  tables  contained  errors  in  at  least  one  of  these  categories: 

•  Incomplete  or  null  column  values; 

•  Inconsistent  naming  conventions; 

•  Rows  not  identified  by  unique  key(s); 

•  Redundant  columns  (as  well  as  tables); 

•  Contradictory  values  between  tables; 

•  Obsolete  columns — not  supported  by  current  rules,  policies,  and 
constraints. 

In  order  to  maintain  a  high  degree  of  data  quality,  we  had  to  perform  lengthy  data 
preparation  and  migration  steps.  In  the  following  discussion,  we  explain  some  of  the 
challenges  we  faced  preparing  the  legacy  database  files,  and  eventually  migrating  them  to 
our  prototype. 

2.  SERVICEMEMBER  Table 

For  all  of  the  tables,  we  prepared  a  data  crosswalk  to  determine  which  tables  and 
attributes  in  the  existing  database  files  would  migrate  into  our  tables.  Table  5-1  shows 
the  data  crosswalk  for  the  SERVICEMEMBER  table. 
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COLUMN  TO  FILL 

SOURCE  TABLE 

SOURCE  COLUMN 

SSN 

ASPRS  (FAMIS) 

AS_SSNO 

LastName 

ASPRS 

AS.LNME 

FirstName 

ASPRS 

AS_FNME 

MI 

ASPRS 

AS_MNME 

Paygrade 

ASPRS 

AS_PGRD 

BranchOfService 

ASPRS 

AS.BSER 

DateOfRank 

ASPRS 

AS_RNKD 

PRD 

ASPRS 

AS_PRDT 

NumberOfFamilyMembers 

ASPRS 

AS_DEPD 

Command 

ASPRS 

AS_COMD 

Priority 

ASPRS 

AS_PRIO 

HomePhone 

ASPRS 

AS_HMEP 

WorkPhone 

ASPRS 

AS.WRKP 

SpouseWorkPhone 

ASPRS 

AS_SWRP 

Email 

*  (No  Match) 

BedRoomsRequested 

ASPRS 

AS_BEDS 

BedRoomsAuthorized 

ASPRS 

AS_BEDR 

DeferMFHUntilDate 

ASPRS 

AS.DDRF 

ControlDate 

ASWTLD  (FAMIS) 

AS_CDTE 

Pets 

*  (No  Match) 

Weapons 

*  (No  Match) 

Medical 

ASPRS 

AS.HAND 

Remarks 

ASPRS 

AS.RMKS 

Designation  FK 

HIUNT  (FAMIS); 
LAMHIST,  PROJECTION 
HISTORY  (HWC) 

HLUNTP 

Desig#,  Res-cat 

BaseName  FK 

HIUNT  (FAMIS); 

LAMHIST,  PROJECTION 
HISTORY  (HWC) 

HI.PNME 

Park 

Table  5-1.  SER VICEMEMBER  Table  Data  Crosswalk 
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The  crosswalk  shows  that  many  of  the  attributes  in  our  SER VICEMEMBER  table 
match  attributes  in  the  FAMIS  table,  ASPRS.  However,  we  also  see  that  the  existing 
database  has  no  attributes  describing  a  service  member’s  Email  address.  Neither  does  it 
track  whether  or  not  s/he  will  have  pets  or  weapons  in  MFH.  Therefore,  these  attributes 
will  contain  null  values  initially;  however,  once  we  implement  the  prototype  and  create 
new  records,  we  will  be  able  to  track  these  attributes.  The  last  two  attributes. 
Designation  FK  and  BaseName  FK.  are  both  foreign  keys  that  must  be  extracted  from 
multiple  tables,  after  we  migrate  more  data  into  our  prototype. 

After  migrating  data  from  the  ASPRS  table,  we  checked  for  duplicate  records. 
Access  2000  provides  a  convenient  wizard,  shown  in  Design  View  in  Figure  5-1,  to  query 
tables  for  duplicate  records.  Using  this  feature.  Access  reported  finding  over  30  duplicate 
records,  summarized  in  Table  5-2,  mostly  resulting  from  partially  completed  records,  or 
multiple  housing  assignments.  The  FAMIS  database  did  not  recognize  the  SSN  attribute 
as  unique,  allowing  users  to  enter  duplicate  records  for  service  members.  We  deleted  the 
duplicate  records  with  the  poorest  data  quality.  For  example,  in  Figure  5-1,  we  deleted 
the  first  record  for  Christopher  Lehner  because  it  did  not  list  his  MFH,  while  the  second 
record  did.  Now,  we  ran  the  query  again.  Access  returned  a  null  report,  allowing  us  to 
set  the  SSN  as  the  key  for  the  SER  VICEMEMBER  table. 
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13 

hhIIH 

LEHNER 

CHRISTOPHER 

1 

03 

CO 

CVJ 

o 

CO 

LEHNER 

CHRISTOPHER 

03 

|425272222l 

LEWIS 

ANGELA 

M 

E5 

14252722221 

LEWIS 

is 

■■ 

miiiiB 

1 

■■ 

6021933331 

6001 

mllmlllm 

02  1 

Table  5-2.  Query  Results  for  Duplicate  Records 


3.  MFHUNIT  Table 

The  MFHUNIT  table  represents  the  military  houses  and  apartments  managed  by 
the  HWC.  Again,  we  performed  a  data  crosswalk  and  mapped  out  the  attributes.  Since 
we  planned  on  using  most  of  the  attributes  from  the  FAMIS  table,  HIUNT,  we  decided  to 
import  the  table,  change  the  data  definitions  to  match  our  design,  and  save  the  table  under 
the  new  name,  MFHUNIT.  After  importing  the  HIUNT  table  from  the  FAMIS  database, 
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we  used  the  MS  Access  design  view,  as  shown  in  Figure  5-2  below,  to  implement  the 
data  crosswalk  and  create  the  MFHUNIT  table.  The  column  Field  Name  displays  the 
initial  MFHUNIT  attribute  names,  Data  Type  displays  the  domain,  and  Description 
contains  our  input  for  the  new  attribute  names.  We  deleted  the  few  fields  that  we  did  not 
need  from  our  table,  such  as  HI_0107.  Upon  closer  examination  of  the  data,  however,  we 
noticed  serious  data  inconsistencies  and  other  potential  problems. 

Many  of  the  FAMIS  and  Access  tables  contained  null  values  in  columns  that 
should  have  been  complete.  We  noticed  that  about  10%  of  the  records  in  the  FAMIS 
table  HIUNT  contained  null  values  for  the  building  number  (facility  number)  column, 
even  though  other  tables,  such  as  the  Access  POMAFAC  table,  contained  the  correct 
information.  For  example,  the  unit  located  at  302  Ardennes  Circle  did  not  have  a 
building  number  in  the  table,  however  over  90%  of  the  records  had  an  entry.  We  found 
the  correct  building  number  in  the  POMAFAC  table  under  the  FAC#  column,  and  later 
created  a  query  to  update  the  values. 

Another  problem  with  the  data  was  misspelled  words.  For  example,  a  street  name 
in  the  HWC’s  history  table  for  OMC,  ANNHIST2,  was  misspelled  “BOUGAINVILL”. 
In  order  to  get  the  addresses  to  a  common  definition,  we  performed  queries  to  add  the 
street  name  suffixes.  When  we  searched  for  the  correct  spelling  “BOUGANVILLE”,  we 
did  not  find  any  units  on  that  street.  After  finding  the  mistake,  we  were  able  to  change 
the  name  to  “BOUGANVILLE  ROAD”.  This  kind  of  error  will  not  occur  in  our 
prototype  because  we  will  use  drop  down  lists  and  validation  rules  in  Access. 
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Figure  5-2. 
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Unfortunately,  the  Housing  Office  Access  tables  had  many  inconsistencies  that 
made  the  preparation  and  migration  process  extremely  tedious  and  time-consuming. 
Because  FAMIS  was  neither  flexible  nor  user  friendly,  the  HWC  created  two  other  tables 
in  an  MS  Access  database,  POMAFAC  and  LA-FAC,  to  track  other  information  about 
MFHs.  The  Access  and  FAMIS  tables,  summarized  in  Tables  5-3  through  5-5,  did  not 
have  compatible  attributes  with  which  to  relate  the  tables.  We  had  to  manipulate  the  one 
common  attribute  type,  address  column,  in  order  to  get  them  on  a  common  naming 
convention,  thus  making  unique  keys  that  we  could  then  join  in  an  Access  query.  For 
example,  the  FAMIS  table  HIUNT  used  the  key  HI_NUMB  to  distinguish  unique  units. 
The  key  for  the  POMAFAC  table,  used  to  track  OMC  neighborhoods,  was  the  FAC- 
REC#  column,  which  was  not  compatible  with  the  HI_NUMB  column,  nor  any  other 
columns  in  the  HIUNT  table.  The  key  for  LA-FAC  was  also  named  FAC-REC#,  which 
we  eventually  matched  with  the  unique  identifier  in  HIUNT,  the  HI_NUMB  column. 

By  this  point,  we  had  recorded  over  five  different  address-naming  conventions 
that  prohibited  us  from  relating  several  tables,  including  MFHUNIT.  In  addition  to  the 
address-naming  conventions  shown  in  Tables  5-3  through  5-5,  other  database  tables 
contained  addresses  with  spaces  and  dashes  separating  the  street  names,  numbers,  and 
apartments,  such  as  “372-C  Bergin  Drive”  and  “372  C  Bergin  Drive”.  Another  problem, 
exhibited  in  Table  5-5,  is  that  in  some  tables,  the  address  components  were  placed  in  one 
field,  while  the  other  tables  split  the  apartment,  street  number,  and  street  name  into 
separate  fields.  We  created  several  queries  in  Access  that  manipulated  the  fields,  either 
concatenating  or  separating  the  address  components.  Then,  we  created  a  lookup  table. 
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shown  in  Figure  5-3,  to  query  and  update  the  addresses  to  calibrate  them  to  the  same 


standard. 


HLNUMB 

HLSNAM 

HLSNUM 

HI  APTN 

1 

BERGIN  DRIVE 

370 

A 

10 

BERG  IN  DRIVE 

371 

B 

100 

BERGIN  DRIVE 

387 

0 

101 

BRITTANY  ROAD 

415 

102 

CORREGIDOR  ROAD 

166 

103 

BIDDLE  LANE 

3 

104 

BIDDLE  LANE 

4 

Table  5-3.  Summarized  FAMIS  Unit  Inventory  Table,  HIUNT 


No# 

STREET 

FAC-REC# 

300 

AACHEN  ROAD 

P06544 

301 

AACHEN  ROAD 

P06530 

302 

AACHEN  ROAD 

P06543 

303 

AACHEN  ROAD 

P06531 

304 

AACHEN  ROAD 

P06542 

305 

AACHEN  ROAD 

P06532 

306 

AACHEN  ROAD 

P06541A 

Table  5-4.  Summarized  Housing  Office  Unit  Inventory  Table,  POMAFAC  (OMC 

Neighborhood) 


FAC-REC# . 

RES  ADD 

1 

370  A  BERGIN  DRIVE 

2 

370  B  BERGIN  DRIVE 

3 

370  C  BERGIN  DRIVE 

4 

370  D  BERGIN  DRIVE 

5 

370  E  BERGIN  DRIVE 

6 

370  F  BERGIN  DRIVE 

7 

370  G  BERGIN  DRIVE 

Table  5-5.  Summarized  Housing  Office  Unit  Inventory  Table,  LA-FAC  (La  Mesa 

Neighborhood) 
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Figure  5-3.  Address  Lookup  Table 


Another  address  naming  convention  problem  involved  tables  containing  street 
suffixes,  such  2&  Drive  or  Street,  which  other  tables  did  not.  Again,  the  address  was  the 
only  common  attribute  name  that  we  could  use  to  relate  some  of  the  tables,  so  we  had  to 
find  a  way  to  standardize  the  addresses  across  the  tables.  We  created  a  lookup  table, 
shown  in  Figure  5-4,  that  we  used  in  update  queries  to  modify  the  street  names. 
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Figure  5-4.  Street  Name  and  Suffix  Lookup  Table 
4.  ASSIGNMENT  Table 

The  assignment  history  table  in  FAMIS,  ASHDT,  was  missing  one  of  the  most 
important  attributes  in  many  records— assignment  dates.  We  designed  the  table  such  that 
the  key  included  the  date  of  assignment  to  MFH,  however,  some  of  the  records  had  a  null 
value  in  the  field.  Access  will  not  allow  key  columns  to  contain  null  values.  We  had  to 
search  the  database  for  such  records  and  determine  the  most  likely  assignment  date,  based 
on  other  clues,  such  as  the  application  date  and  the  vacate  dates. 


Unfortunately,  in  some  records,  the  vacate  date  was  also  null.  Therefore,  we  had 
to  search  other  database  tables,  like  the  SER VICEMEMBER  table,  to  find  any 
information  that  would  help  fill  our  table. 
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MCNEIL 

Table  5-6.  Assignment  History  Table  with  Null  Values  in  the  AS-ASGN  Column 

(Date  of  Assignment) 


We  realized  that  this  detective  work  was  error-prone,  especially  in  the  case  where 
the  HI_VACT  field  was  also  null  (and  therefore  we  could  not  estimate  the  assignment 
date  based  on  the  vacate  date).  However,  our  main  goal  was  to  create  a  key,  even  if  the 
assignment  date  was  off  by  a  few  months.  Most  of  the  affected  records  were  over  five 
years  old  and  the  HWC  does  not  require  more  precision  for  its  business  process. 

Another  duplication  problem  in  the  assignment  history  table  was  that  there  were 
duplicate  history  entries  for  SMs  who  were  promoted  after  they  moved  into  MFH.  The 
HWC  does  not  normally  know  when  a  SM  is  promoted,  however,  it  appears  that 
whenever  the  HWC  updated  the  SM’s  record  in  FAMIS,  the  application  automatically 
added  a  new  record  to  the  history  table,  even  though  the  SM  did  not  move  to  another 
MFH. 


As  with  the  SERVICEMEMBER  table,  we  queried  the  ASSIGNMENT  TABLE 
to  find  duplicate  records,  then  deleted  the  duplicate  record  in  the  pair  with  the  least 
amount  of  information  about  the  assignment. 
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5.  FAMILYMEMBER  Table 

We  found  two  source  tables  for  the  FAMILYMEMBER  data  migration:  one  for 
dependents  currently  living  in  MFH,  and  one  for  past  occupants.  The  family  member 
historical  table  in  FAMIS  (ASDPS)  contained  over  10,300  records.  Of  those,  almost 
1200  were  duplicate  records.  Normally,  the  key  attributes  for  this  table  would  be  SSN 
and  RelationCode.  Because  many  of  the  columns,  such  as  BirthDate  and  RelationCode, 
had  null  values,  we  could  not  designate  a  key  for  the  table.  We  decided  to  create  an  auto 
number  column  as  the  key  and  use  the  SSN  to  link  the  family  members  to  service 
members.  We  were  able  to  import  the  table  for  current  occupants  using  the  same  process; 
however,  after  importing  the  table  we  were  able  to  create  a  more  meaningful  key  using 
the  SSN,  FirstName,  and  BirthDate  columns  (which  were  not  null  in  this  table). 

6.  FLOORPLAN  Table 

After  reviewing  this  table,  we  found  another  example  of  multiple  naming 
conventions.  The  unit  designation  field  was  defined  in  several  ways,  depending  on  the 
table.  For  example,  the  FAMIS  table  tracked  the  designation  for  a  3-bedroom  floor  plan, 
allocated  for  field  grade  officers,  as  either  “3BD  FG-LM”  or  “3BD  FG-PA”,  depending 
on  the  base  in  which  the  unit  is  located.  Several  of  the  HWC  Access  tables  defined  the 
units  as  either  “3FG”  or  “FG-3BD-2BT”,  depending  on  the  table  (and  the  base).  In  order 
to  get  the  same  designation  for  each  unit,  we  queried  the  FLOORPLAN  table  and  joined 
it  with  the  MFHUNIT  table  as  shown  in  Figure  5-5.  Then,  we  created  a  new  MFHUNIT 
table  with  a  standard  naming  convention  for  the  Designation  column. 
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Figure  5-5.  Updating  the  Designation  Column 


7.  APPLIANCE  Table 

The  HWC  uses  two  Access  tables  to  track  appliances:  one  for  OMC  and  POM, 
and  one  for  NPS  and  La  Mesa.  The  Access  tables  for  tracking  appliances  are  flat  files — 
they  don’t  relate  to  an  appliance  entity.  If  you  delete  an  MFH  record  in  the  table,  the 


appliances  are  also  deleted.  According  to  the  HWC,  every  MFH  should  have 


government-owned  appliances,  such  as  refrigerators,  dishwashers,  and  stoves.  Given  that 


the  HWC  manages  about  2,200  units,  they  should  maintain  information  on  approximately 


6,600  appliances.  However,  the  HWC  Access  tables  only  contain  1,150  appliances. 
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FAC-REC 

Res  Add 

REF  TYPE 

SER. 

DISHWASHER 

TYPE 

SER 

1 

370  A  BERGIN  DRIVE 

SUNRAY 

9306136020 

WHIRLPOOL 

SX1 728763 

HOTPOINT 

U2601649 

2 

370  B  BERGIN  DRIVE 

3 

370  C  BERGIN  DRIVE 

4 

370  D  BERGIN  DRIVE 

SUNRAY 

9306136031 

GIBSON 

0348602292 

HOTPOINT 

UX601670X 

5 

370  E  BERGIN  DRIVE 

SUNRAY 

9110158970 

HOTPOINT 

U2601669X 

Table  5-7.  Original  Appliance  Tracking  Table  for  La  Mesa,  LA-APPL 

First,  we  exported  the  Appliance  tables  (APP-POMA  and  LA-APPL)  to  Excel, 
copied  the  UnitlD  column  in  front  of  each  appliance  type  column,  and  linked  the  unit 
with  the  appliances.  Next,  we  added  columns  to  specify  the  type  of  appliance.  Then,  we 
cut  and  pasted  the  information  in  order  to  align  the  appliances  into  unique  rows,  as  shown 
in  Table  5-8. 


UnitlD 

TypeOf  Appliance 

Manufacturer 

SerialNumber 

1 

S 

SUNRAY 

9306136020 

2 

S 

3 

s 

4 

s 

SUNRAY 

9306136031 

5 

s 

SUNRAY 

9110158970 

Table  5-8.  Creating  Unique  Appliances 


Still  in  Excel,  we  added  a  unique  number  to  each  appliance,  resulting  in  Table  5- 
9,  which  we  then  exported  to  the  APPLIANCE  table  in  our  Access  database. 
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AppliancelD 

Unitro 

TypeOfAppliance 

Manufacturer 

SerialNumber 

1 

1 

s 

SUNRAY 

9306136020 

2 

2 

s 

3 

3 

s 

4 

4 

s 

SUNRAY 

9306136031 

•  •  » 

* . . 

... 

576 

1 

R 

WfflRLPOOL 

SX1728763 

577 

2 

R 

WfflRLPOOL 

SX1728991 

578 

3 

R 

SX1728976 

579 

4 

R 

GIBSON 

0348602292 

«  .  , 

1151 

1 

D 

HOTPonsrr 

U2601649 

1152 

2 

D 

HOTPOINT 

U2601111 

1153 

3 

D 

HOTPOINT 

U2601102 

1154 

4 

D 

HOTPOINT 

UX601670X 

Table  5-9.  Summary  of  the  Completed  APPLIANCE  Table 


Finally,  we  used  the  query  in  Figure  5-6  to  weed  out  null  records,  such  as  the 
second  and  third  records  from  Table  5-9  (above),  and  create  our  APPLIANCE  table. 
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Figure  5-6.  Access  Query  to  Weed  Out  Null  Appliance  Rows 

8.  PRIVATERENTALPROPERTY  Table 

Some  of  the  address  information,  such  as  city  and  zip,  were  missing  from  a 
significant  number  of  records.  Initially,  we  planned  to  place  only  the  zip  in  the  table, 
linking  it  to  our  ZIPCODE  table,  which  contains  the  city  and  state  for  each  unique  zip. 
However,  for  our  prototype,  we  decided  to  leave  the  fields  and  migrate  them  “as  is”  for 
the  referral  portion. 

In  this  table,  we  also  noticed  data  entry  errors.  One  example  is  in  the  RF_DDEL 

column,  which  is  the  date  to  delete  the  referral  listing.  An  unknown  system  user  at  the 

HWC  entered  2270”  for  one  of  the  referral  properties,  meaning  that  the  owner  wishes  to 

remove  the  referral  listing  269  years  from  now!  We  assumed  that  this  was  either  a  data 
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entry  error,  or  the  owner  had  great  long-term  property  management  skills.  We  can  only 
guess  his/her  intention.  In  order  to  truly  clean  this  kind  of  error  in  the  table,  someone  at 
the  HWC  would  need  to  verify  the  information  through  other  sources. 

C.  SUMMARY 

We  began  the  data  migration  process  with  a  physical  database  design  and  over  80 
separate  operational  data  files  from  the  HWC.  In  order  to  migrate  the  operational  data 
into  our  database,  we  had  to  perform  thorough,  sometimes  tedious,  data  cleansing  to  find 
the  desired  data.  While  finding  the  correct  data  and  understanding  the  existing  schema 
was  difficult  enough,  we  needed  a  data  crosswalk  in  order  to  map  out  the  data’s  migration 
path.  Not  only  did  we  extract  data  from  FAMIS,  but  we  also  had  to  extract  and  contour 
the  flat  files  found  in  the  HWC’s  Access  database. 

We  encountered  many  data  quality  issues  as  we  migrated  the  data.  Normally  just 
harmless  mistakes,  misspelled  words  created  relational  roadblocks  in  our  tables.  Other 
data  issues,  such  as  inconsistent  naming  conventions  and  null  column  values,  tested  our 
querying  abilities  and  forced  us  to  leam  the  schema  inside  out.  In  the  end,  however,  we 
successfully  converted  the  data  into  our  prototype,  allowing  us  to  move  on  and  create  the 
user  interface. 
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VI.  PROTOTYPE  IMPLEMENTATION 

A.  INTRODUCTION 

Database  tables  by  themselves  are  boring  and  non-intuitive  as  a  basis  for  users  to 
perform  business  tasks.  The  tables  alone  cannot  capture  the  business  process  and  enforce 
business  rules.  In  order  to  perform  efficient  operations  on  multiple  records  in  tables, 
users  need  to  know  a  query  language,  such  as  the  standard  structured  query  language 
(SQL).  However,  for  the  HWC,  as  is  the  case  for  an  ordinary  business,  we  do  not  require 
each  user  to  possess  SQL  skills — ^that  would  create  an  unnecessary  training  burden. 
Instead,  we  take  advantage  of  numerous  database  applications  available  in  the  software 
market.  Database  applications,  such  as  Access,  provide  five  major  functions: 

•  Create,  read,  update,  and  delete  (CRUD)  views; 

•  Materialize  or  format  views; 

•  Enforce  constraints; 

•  Provide  security  and  control  mechanisms; 

•  Execute  business  logic  (Kroenke  267). 

It  came  as  no  surprise  that  potential  users  of  our  system  expected  an  easy  to  use 
graphical  user  interface  (GUI),  whether  through  the  database  application,  or  an  Internet 
browser.  Therefore,  we  needed  to  create  a  series  of  layered  menus  in  Access,  known  as 
switchboards,  as  the  primary  front-end  to  the  database.  Beneath  each  menu,  we  also 
needed  to  create  the  relevant  forms,  reports,  and  other  functions  provided  by  a  database 
application  to  satisfy  the  requirements  identified  in  the  use  cases. 

Because  one  of  our  use  cases  required  implementing  Internet-based  housing 
applications,  we  also  needed  to  design  the  Web-based  GUI  and  provide  connectivity  to 
the  HATS  database. 
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B.  FORMS 


Since  our  system  requirements  identified  Access  as  the  users’  interface  with  the 
database,  we  created  menu  views  to  allow  point  and  click  navigation.  In  Access,  a 
switchboard  is  the  equivalent  of  a  menu.  It  is  just  another  form  that  allows  us  to  place 
text,  pictures,  and  buttons  on  the  screen  to  facilitate  user  interaction  with  the  system.  The 
main  switchboard,  shown  in  Figure  6-1,  displays  several  command  buttons,  each  labeled 
after  the  functions  identified  in  our  functional  decomposition. 


Figure  6- 1 .  HATS  Main  Menu  (Switchboard  Form) 


Each  function’s  command  button  links  the  user  to  the  next  level  of  functions.  For 


example,  the  main  switchboard  acts  as  the  main  menu  for  HATS.  The  “Assignments  and 
Terminations”  button  on  the  main  form  links  the  user  to  the  “Assignments  and 
Terminations”  functions  in  the  level-2  functional  decomposition.  From  that  menu,  each 
button  links  the  users  to  forms,  reports,  and  other  functions  specified  in  the  use  cases. 

We  returned  to  the  use  cases  in  Appendix  A  and  analyzed  them  to  determine  what 
forms  the  users  of  our  system  may  need  to  interact  with  the  database.  Table  6-1  lists  the 
name  and  purpose  of  each  form  and  traces  the  requirement  back  to  the  use  cases. 

We  used  tools  in  Access  to  create  our  forms  and  enforce  the  HWC’s  business 
rules.  Almost  all  of  our  forms  were  designed  to  use  drop  down  menus,  check  boxes,  or 
other  controls  to  limit  a  user’s  input  to  match  valid  domains.  For  example,  in  order  to 
edit  a  service  member’s  record  using  the  edit  SM  form  in  Figure  6-2,  the  user  must  select 
an  SSN  from  a  drop  down  menu,  which  forces  the  user  to  input  a  valid  SSN.  Otherwise, 
the  user  could  type  an  incorrect  SSN  and  the  application  would  display  an  error  message, 
indicating  that  no  such  record  exists. 
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Form  Name 

Form  Purpose 

Use  Case 

DD  Form  1746 

Application  for  Housing 

UC  10 

Add  SM  to  List 

Add  SM  to  a  Waiting  List 

UC  25 

Edit  SM 

Edit  SM  Information 

UC15 

NewCRL 

Enter  CRL  Search  Criteria 

UC  60 

Edit  Wait  Status 

Edit  SM  Wait  Status 

UC35 

Edit  Freeze 

Edit  Freeze  Zone 

UC40 

Match  SM  MFH 

Match  SM  with  an  MFH 

UC45 

Offer  MFH 

Offer  MFH  to  SM 

UC  45 

Assign 

Make  an  Assignment 

UC  50 

Intent  to  Vacate 

File  Intent  to  Vacate  and  Schedule 
Clearance  Inspections 

UC  55 

Terminate 

Terminate  Assignment 

UC  55 

Update  MFH 

Update  MFH  Attributes 

UC  65,  85 

Add  MFH 

Add  MFH  to  the  System 

UC  65 

Delete  MFH  from  the  System 

UC75 

Add  PR  Property 

Add  Private  Rental  Property 

UC70 

Update  PR  Property 

Update  Private  Rental  Property 

UC70 

Delete  PR  Property 

Delete  Private  Rental  Property 

UC  75 

Add  Owner 

Add  Property  Owner  Information 

UC  80 

Update  Owner 

Update  Owner  Information 

'UC80 

Delete  Owner 

Delete  Property  Owner  from  System 

UC80 

Table  6-1 .  Forms  Required  According  to  Use  Cases 
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Figure  6-2.  Using  Drop-down  Menus  on  Forms 
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C.  PROVIDING  INTERNET  CONNECTIVITY  TO  THE  DATABASE 

Since  one  of  the  main  goals  of  our  protot5^e  was  to  demonstrate  online 
application  processing,  we  created  a  test  HWC  Web  page  and  linked  it  to  our  database 
using  common  Web  applications  and  technologies:  Web  serving  and  development 
applications,  Active  Server  Pages  (ASP),  and  Open  Database  Connectivity  (ODBC). 

Active  Server  Page  (ASP)  is  a  Microsoft  Internet  Information  Server  (IIS)  feature 
that  supports  scripting  languages  to  interact  with  applications,  such  as  a  DBMS.  The 
ASP  code  is  part  of  the  source  code  on  the  Web  page,  which  is  written  in  Hyptertext 
Mark-up  Language  (HTML).  It  is  the  ASP  code  that  carries  out  the  instructions  to  insert 
the  data  from  the  Internet  application  form  into  the  HATS  database  tables. 

Open  Database  Connectivity  (ODBC)  is  a  standard  application  program  interface 
(API)  for  connecting  application  programs  to  databases  (Kroenke,  2000,  p.  342).  By 
using  ODBC,  we  can  link  our  Web  site  (application)  to  our  database  through  the 
connections  shown  in  Figure  6-3.  One  advantage  to  using  the  ODBC  standard  is  that  if 
someone  decides  to  move  HATS  to  another  DBMS,  such  as  Oracle,  the  HWC  would  only 
need  to  configure  another  ODBC  connection.  They  would  not  need  to  make  any  changes 
in  either  the  Web  site  or  the  database.  Since  we  used  the  Access  DBMS,  we  configured 
the  Web  host  server’s  ODBC  connection  to  allow  access  to  the  data  source  (our  prototype 
database)  using  an  Access  DBMS  driver. 
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Web  Server 


Database  Server 


Figure  6-3.  ODBC  Architecture  in  Relation  to  HATS  (After  Kroenke,  2000,  p.  343) 

Before  we  connecting  our  prototype  to  the  world,  including  some  Internet 
browsers  with  malicious  aspirations,  we  decided  to  implement  a  minor  safeguard  to 
protect  the  integrity  of  one  of  the  main  tables  (SERVICEMEMBER).  We  created  a 
staging  table  (shown  in  Figure  6-4),  APPLICANT,  to  record  information  about  service 
members  applying  for  housing.  When  service  members  submit  their  personal 
information  to  the  HWC  through  the  ASP  site,  the  data  is  stored  in  the  APPLICANT 
table.  Otherwise,  anyone  could  enter  data  into  the  SERVICEMEMBER  table  and  the 
HWC  would  have  to  screen  the  table  for  data  entry  anomalies.  By  creating  the 
APPLICANT  table,  the  HWC  can  screen  the  information,  then  without  re-typing  data, 
click  a  macro  button  and  transfer  the  information  to  the  SERVICEMEMBER  table. 

Using  Microsoft  FrontPage  2000,  we  created  a  simplified  version  of  the  HWC’s 
housing  application  (DD  Form  1746).  FrontPage  has  Web  form  creation  tools  that  make 
the  process  as  easy  as  pointing  and  clicking.  In  addition,  FrontPage  created  the  ASP 
commands,  so  we  did  not  have  to  learn  another  sub-language  for  this  task.  In  order  to 
complete  the  other  end  of  the  ODBC  loop,  we  opened  the  form  properties  in  FrontPage 
and  routed  the  results  of  the  application  to  our  database. 
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Figure  6-4.  APPLICANT  Table  for  Recording  Online  Applications 

Finally,  we  published  our  housing  application  (DD  Form  1746),  shown  in  Figure 
6-5,  on  a  Microsoft  Internet  Information  Server  (version  4).  We  tested  the  connection  by 
entering  fictitious  applications  through  a  Web  browser,  then  confirming  that  the 
applications  were  successfully  added  to  the  APPLICANT  table  in  our  prototype. 
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MONTEREY  BAY 

MILITARY  HOUSING  -  ONLINE! 

APPLICATION  FOR  ASSIGNMENT  TO  HOUSING 


SSN 

-  - 

Paygrade 

\Piz\ 

Last  Name 

1  . . 

Branch  of  Service  I  Navy 

"la 

First  Name 

Report  Date  mm/ddiVyyy  i 

MI 

_ 

CZj 

If 

Address 

. ^ 

(Street,  City,  State,  Zip) 

Email  f 

Marital  Status 

1  Married 

Daytime  Phone  1 

Separated  From  Dependents?  I  No 

Evening  Phone  1 

Request  Housing  For 

|Self  and  Family  ='^1 

Assignment  (in  Monterey)[ 

Student  NPGS 

"Sl  Total  Bedrooms  Authorized 

El 

Departing  Command  | 

Remarks 

. M 

Submit  1  Reset  | 

Figure  6-5.  Summarized  Version  of  the  Housing  Online  Application  (DD  Form  1746) 
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D.  REPORTS 


Just  as  we  determined  which  forms  we  needed  to  create,  we  returned  to  the 
requirements  analysis  phase  of  our  prototype  to  identify  the  required  reports.  The  “View 
and  Print  Reports”  use  case,  UC  90,  stated  that  users  need  several  reports,  which  we 
identified  in  our  functional  decomposition  and  summarized  in  Table  6-2. 


Reports 

Frequency 

Wait  Lists 

Weekly 

Housing  Statistics 

Monthly 

Coast  Guard 

Monthly 

Mayors’ 

Monthly 

Vacate 

Monthly 

Occupants 

Monthly 

Non-eligible 

Quarterly 

Utilization 

Annually 

School  Children 

As  Needed 

Assignment  History 

As  Needed 

Table  6-2.  Reports  Derived  From  Functional  Decomposition  (and  UC  90) 

Figure  6-6  shows  a  segment  of  the  monthly  occupant  report,  which  is  organized 
by  neighborhood,  then  by  address.  We  created  this  report  from  a  query  that  searches  for 
all  current  assignments.  Using  the  same  process,  we  created  the  remainder  of  the  reports 
listed  in  Table  6-2.  These  are  shown  in  Appendix  D. 
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Occupant  Report 


INeighborhood 
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3 

Figure  6-6.  Occupant  Report 


E.  SUMMARY 

After  creating  database  tables,  we  implemented  the  features  of  a  database 
application  (Access)  to  provide  the  reports,  forms,  views,  and  other  functions  necessary 
to  support  the  HWC’s  business  process.  We  created  a  GUI  within  Access  to  facilitate 
easy  navigation  between  the  system’s  functions. 

Because  the  system  requires  Internet-based  input,  we  created  a  GUI  for  Internet 

users  and  confirmed  that  information  entered  via  this  GUI  was  inserted  into  our  database. 

By  using  common  Web  design  and  publication  applications,  we  were  able  to  create  a 

simple  housing  application  form  on  the  Internet  and  establish  a  link  to  our  database. 

Although  a  prototype,  the  Web  page  successfully  inserts  service  member  applications  to 

the  HWC,  eliminating  the  need  for  the  HWC  to  re-type  information. 
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As  with  any  prototype,  our  system  can  benefit  from  several  iterations  of  user 
feedback  before  going  “full  up”.  As  much  as  we  attempted  to  make  the  GUI  useful  and 
intuitive,  we  cannot  expect  to  capture  their  needs  on  the  first  attempt.  In  addition,  since 
we  performed  an  intensive  data  migration  effort,  any  plans  to  develop  a  “full  up”  system 
should  include  a  data  verification  procedure  before  going  live. 

For  an  operational  system  we  recommend  migrating  to  more  powerful 
applications,  such  as  Dreamweaver  for  Web  design  and  Oracle  for  the  database. 
Although  Frontpage  is  easy  to  use,  it  is  not  as  robust  as  Dreamweaver,  which  is  preferred 
by  the  majority  of  professional  Web  designers.  As  for  the  database  application,  Oracle’s 
database  is  far  superior  in  terms  of  performance,  but  more  expensive  than  Access. 

We  used  Access  in  the  prototype  for  two  main  reasons.  First,  we  were  familiar 
with  the  development  GUI  and  convenient  interfaces  with  other  Microsoft  applications, 
such  as  Frontpage,  Word,  and  Excel.  Second,  the  HWC  already  owned  the  software 
license  for  Access,  so  there  would  have  no  additional  expense  for  implementing  the 
prototype. 

Ideally,  the  front-end  to  the  system  should  eventually  reside  on  the  Web.  By 
using  an  Internet  browser  as  the  GUI  to  the  database,  the  HWC  users  and  its  customers 
can  interact  with  the  system  using  a  wide  range  of  Internet  browsing  devices,  including 
personal  data  assistants  (PDAs).  Additionally,  the  HWC  would  not  need  to  purchase  and 
install  Access  on  their  data  entry  devices. 
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VII.  DECISION  SUPPORT  TOOLS 


A.  INTRODUCTION 

Up  to  this  point,  we  have  created  a  relational  database  with  a  user-friendly  GUI  to 
input  and  edit  data  and  view  text  reports.  What  we  have  not  done  yet  is  provide  tools  for 
users  to  manipulate,  organize,  and  analyze  data  and  information  in  order  to  make  better 
decisions.  A  decision  support  tool  (DST)  is  any  tool  that  enhances  the  ability  of  humans 
to  make  decisions.  Our  goal  is  to  provide  tools  that  transform  data  and  information  into 
knowledge  (illustrated  in  Figure  7-1),  which  HWC  managers,  counselors,  and  customers 
can  use  to  make  better  housing  utilization  decisions. 


Figure  7- 1 .  DST s  Foster  Knowledge  and  Better  Decisions 


Customers  and  the  HWC  will  have  access  to  data  and  information  through  the 
DBMS  to  formulate  knowledge  and  make  decisions.  However,  because  they  are  human, 
they  are  limited  in  their  capacity  to  process  data  and  information  into  knowledge.  We 
will  provide  DSTs  for  both  the  decision  makers  at  the  HWC— the  HMSs  and  the 
supervisors — and  their  customers,  the  service  member  deciding  which  MFH  s/he  wants  to 
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live  in.  A  poor  decision  about  which  houses  to  offer  (by  the  HWC),  or  which  house  to 
occupy  (by  the  service  member),  can  have  a  serious  impact  on  quality  of  life  and  job 
satisfaction  over  the  duration  of  the  assignment,  possibly  leading  to  negative  impacts  on 
retaining  service  members  in  the  future. 

Often,  robust  DSTs  are  part  of  a  larger,  sometimes  expensive  decision  support 
system  (DSS).  For  our  system,  however,  we  considered  inexpensive,  readily  available 
applications  that  provide  useful  DST  functionality.  Since  we  are  already  using  Access  as 
our  DBMS,  we  decided  to  use  some  of  the  add-on  tools  provided  with  Access.  The  other 
DST  that  we  chose  to  use  is  a  geographic  information  system  (GIS).  Because  many  Web 
sites  today  are  using  GIS  technology,  we  decided  to  implement  a  tool  that  is  gaining  in 
popularity  and  acceptance  in  homes  and  businesses  around  the  world.  Additionally,  GIS 
provides  an  intuitive,  visual  display  of  housing  locations  which  can  assist  the  decision 
makers  and  customers  in  the  housing  assignment  process. 

B.  MICROSOFT  ACCESS  TOOLS 

Since  we  have  created  the  database  application  in  Access,  it  is  only  natural  to  take 
advantage  of  the  convenience  of  the  embedded  tools  in  the  DBMS.  Access  provides 
built-in  functions  that  enhance  a  person’s  ability  to  make  good  decisions.  Some  DSTs 
provided  by  Access  include: 

•  Graphs; 

•  Charts; 

•  Calculations; 

•  Filters; 

•  Queries; 

•  Macros. 
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Some  of  the  DSTs  provide  visual  information,  such  as  graphs,  while  others 
provide  filtered  or  manipulated  views  of  existing  data,  such  as  queries.  The  real  power  of 
Access  is  the  ability  to  combine  tools.  For  example,  users  can  query  the  database  (or 
another  query),  perform  calculations,  filter  the  information,  and  display  the  results  in  a 
graph  or  chart.  Using  these  embedded  tools,  we  can  improve  decisions  about  such 
concerns  as  housing  utilization,  assignment  waiting  queues,  and  other  critical  success 
factors  determined  by  the  HWC. 


In  the  following  example,  we  show  how  to  combine  tools  in  Access  to  create 
views  that  can  enhance  a  user’s  ability  to  make  better  decisions.  First,  we  create  a  new 
table  (shown  in  Figure  7-2)  that  keeps  a  record  of  utilizations  statistics,  such  as  the 
number  of  occupied  and  unoccupied  houses.  The  key  of  the  table  is  Month,  which  is  the 
month  of  the  report  and  the  year.  This  table  allows  the  HWC  to  keep  a  historical 
utilization  file  and  analyze  trends  that  could  help  predict  future  rates. 


Q  Microsoft;  Access 


.  gie  Edk  Insert  lools  ^  , 


IsiumberHoid 


i  Date/Time 


Pate  oF  report;  June^  2001  =  06/2001 


|Number . 

[Number  i#  homes  not  occupied,  on  hold  for  maintenancej  etc.  ^ 


(NumberA^^  [Number 


Figure  7-2.  UTILIZATION  Statistics  Table 
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Next,  we  create  queries  to  generate  the  statistics,  such  as  the  number  of  occupied 
houses,  and  store  the  data  in  the  UTILIZATION  table.  Figure  7-3  illustrates  the  query,  as 
seen  in  the  query  by  example  (QBE)  view  in  Access. 


Figure  7-4.  Access  Query  to  Count  the  Number  of  Occupied  Houses 


Finally,  we  create  a  chart  of  the  utilization  statistics  by  selecting  the 
UTILIZATION  table  and  clicking  on  the  menu  choices,  “Tools,  Office  Links,  Analyze  it 
with  Excel”.  This  tool  loads  the  table  data  into  an  Excel  spreadsheet,  where  we  use  the 
chart  wizard  function  to  quickly  create  a  chart  depicting  the  historical  utilization.  The 
chart,  shown  in  Figure  7-5,  helps  the  HWC  visualize  utilization  patterns  that  may  not  be 
evident  when  viewed  in  tables  or  reports. 
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The  HWC  can  view  the  utilization  chart  by  selecting  the  “View  Utilization 
Statistics”  button  on  the  “Queries  and  Reports”  main  menu.  The  button  contains  a  macro 
that  runs  the  queries,  updates  the  UTILIZATION  table,  and  opens  the  chart  shown  in 
Figure  7-5.  This  chart  could  help  the  HWC  recognize  that  there  is  a  decreasing  trend  in 
the  number  of  occupied  units,  and  an  increasing  trend  in  the  number  of  available  units. 
This  revelation  may  trigger  the  HWC  to  make  decisions  concerning  renovations,  or  other 
utilization  decisions  that  take  advantage  of  this  knowledge. 


2250 . "  i 

2200 


1/1/2001  2/1/2001  3/1/2001  4/1/2001  5/1/2001 


□  Number  Available 
■  Number  on  Hold 
m  Number  Occupied 


Figure  7-5.  Utilization  Chart 

C.  GEOGRAPHIC  INFORMATION  SYSTEM 

So  far,  our  prototype  displays  data  in  forms,  datasheets,  charts,  and  reports.  Since 
the  focus  of  our  system  is  assigning  people  to  houses,  we  have  yet  to  deal  with  the  spatial 
aspect  of  the  assignment  and  termination  process.  Customers  often  want  to  know  where 
prospective  houses  are  located,  or  how  close  they  are  to  schools,  churches,  commissaries. 
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playgrounds,  and  other  families.  According  to  Environmental  Systems  Research  Inc.,  80 
percent  of  all  data  has  a  spatial  component  (2001).  A  picture  is  truly  worth  a  thousand 
words,  or  in  this  case,  several  thousand  words.  Traditional  information  systems  fail  to 
capture  and  display  the  significance  of  spatial  information.  Geographic  Information 
Systems  (GIS)  provide  the  ability  to  present  spatial  data  in  a  meaningful  way  to  provide 
information  that  may  lead  to  knowledge  and  better  decisions. 

A  GIS  is  a  computer  system  for  “capturing,  storing,  checking,  integrating, 
manipulating,  and  displaying  data  using  digitized  maps”  (Aronson,  1998,  p.  243).  A  GIS 
is  more  than  just  a  map — ^it  displays  layers  of  spatial  data  that  can  be  captured  (or  printed) 
in  a  map,  if  desired.  In  addition,  a  GIS  maintains  tables  of  data  that  can  be  queried, 
manipulated,  and  displayed  with  other  layers  for  analysis. 

By  integrating  our  DBMS  with  a  GIS,  we  can  make  a  more  robust  system  that 
displays  visual  information  that  could  otherwise  be  overlooked  by  decision-makers. 
Without  the  GIS,  users  must  interpret  data  from  database  tables,  reports,  and  static  street 
maps.  A  GIS  puts  the  separate  layers  of  data  (as  illustrated  in  Figure  7-6)  into 
perspective,  creating  dynamic  views  of  the  business  environment. 

Data  from  many  sources  can  be  combined  to  create  individual  layers,  that  when 
combined,  create  a  meaningful  view  of  information.  Figure  7-7  illustrates  the  fact  that  a 
GIS  combines  data  from  several  sources  to  create  a  synergistic  and  robust  view  of  the 
research  environment. 

We  chose  ESRFs  Arc  View  (version  3.2)  as  our  GIS  application  for  this  prototype 

primarily  due  to  its  available  and  wide  acceptance  by  business  and  government  agencies. 

Arc  View  allows  users  to  retrieve  data  directly  from  the  database,  which  in  our  case  is  the 
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HATS  database  in  Access.  In  order  to  retrieve  the  data,  we  create  an  ODBC  connection 
with  our  Access  database,  as  illustrated  in  Figure  7-8.  While  connected  to  our  database, 
we  query  the  MFHUNIT  table  and  create  new  tables  in  our  ArcView  project  for  all 
houses,  including  currently  available  houses  and  those  available  in  the  near  future. 


Figure  7-6.  GIS  Layers  of  Data  (From  ESRI) 


ffoitfre  Fhift 


Figure  7-7.  Connecting  Data  Sources  to  a  GIS  Database  (From  ESRI) 


79 


SQL  Connect 


MS  Access  Database 


IlilttSIKiililii 


NEIGHBORHOOD 


i&kimns 


MFHUNIT 


OWNER 

pqry_LaslNanne 

Darv  .Waitlist  ..enter.  Cateaoiv 


YearBuilt 
CatCodeN  umber 
DiversionDate 
Clearance!  nspectionD  ate 


M-CODE 


HWC  . 

'MFHUNIT'.'UnitID'/MFHUNIT'.longAddfess', 

'M  FH  U  N I T '.  'N  eighborhoodName' 

'MFHUNIT' 

. 

MFHOcc 


Figure  7-8.  Querying  the  Database  for  Available  Units  and  Adding  the  Results  as  a 
New  Table  in  ArcView  (Also  Using  ODBC) 


Before  we  can  view  our  houses  in  a  spatial  manner,  we  need  to  add  a  reference 
layer  containing  spatial  data  and  match  our  addresses  with  the  layer.  In  other  words,  we 
need  a  reference  map  with  coordinate  information  that  we  can  overlay  with  address  icons. 
ArcView  shapefiles  are  data  files  containing  such  reference  information,  which  is 
technically  referred  to  as  a  geocoding  index.  First,  we  use  a  shapefile  from  ESRI  (with  a 
geocoding  index  for  our  houses)  as  our  bottom  data  theme.  Next,  we  geocode  our  MFH 
addresses  by  linking  the  address  fields  (street  number,  street  name,  and  five  digit  Zip 
code)  in  the  tables  to  the  geocoding  index  in  the  reference  shapefile.  As  we  match  each 


80 


table  from  our  database,  such  as  the  MFHUNIT  table  with  all  houses  in  the  HWC 
inventory.  Arc  View  creates  a  new  theme  for  each.  Figure  7-9  shows  the  reference  theme, 
named  Street.shp,  and  four  themes  for  housing  status:  available  now,  available  in  less 
than  30  days,  available  in  more  than  30  days  but  less  than  60  days,  and  all  units.  In 
Figure  7-9,  the  Street  theme  and  the  All  Units  themes  are  selected  (as  indicated  by  the 
check  mark  in  front  of  the  theme  name)  and  displayed  in  the  viewing  window.  Users  can 
change  theme  selection  to  capture  a  number  of  different  scenarios.  For  example,  we 
change  views  so  that  a  user  can  display  just  the  houses  currently  available  for  occupancy, 
shown  in  Figure  7-10. 

For  our  system,  users  need  to  drill  down  and  see  more  information  about  the 
themes.  For  example,  they  may  want  to  know  what  category  of  housing  is  available  and 
where  they  are  located.  ArcView  provides  a  query  function  to  select  records  from  a 
theme  based  on  criteria,  such  as  housing  category,  and  highlight  the  query  results  in  the 
theme  view.  For  example,  we  decide  to  specify  a  housing  category  in  the  Available  Now 
theme.  After  making  the  theme  active,  we  view  the  theme  table  containing  all  of  the 
records  for  the  available  houses.  ArcView  provided  a  query  window,  shown  in  Figure  7- 
1 1 ,  to  facilitate  our  query.  We  select  the  category  3JOOMC  (three  bedroom,  junior 
officer,  at  Ord  Military  Community).  Notice  that  ArcView  user  interface  helps  the  user 
select  the  values  for  the  query  by  displaying  all  of  the  valid  values  for  the  category  field. 
After  making  our  selection,  ArcView  displays  the  entire  theme  table  and  highlights  the 
matching  records,  as  shown  in  Figure  7-12.  More  importantly,  ArcView  also  updates 
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Figure  7-9.  View  of  All  Units  Theme  with  Occupied  Units  Highlighted 
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Figure  7-10.  View  of  Available  Units 


the  theme  view,  shown  in  Figure  7-13,  to  give  the  user  a  more  useful  visual  of  the  query 
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Figure  7-11.  Selecting  a  Housing  Category  to  View 
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Figure  7-12.  Result  of  Query  for  Category  “3  JOOMC”  Houses 


Figure  7-13.  Map  Showing  Category  “3JOOMC”  Available  Units 
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Based  on  our  experiences,  one  of  the  most  important  criteria  for  housing  selection 
is  the  demography  of  the  area.  Service  members  and  family  members  want  to  know  the 
number  and  characteristics  of  the  people,  in  relation  to  their  age,  for  example.  More 
specifically,  parents  are  concerned  about  the  ages  of  the  children  in  the  area  because  they 
want  their  own  children  to  have  playmates  close  to  their  house.  Because  our  protot)^e 
HATS  database  contains  a  FAMILYMEMBER.Birthdate  field,  we  can  extract  the  ages  of 
children  from  our  database  and  create  demographic  overlays  to  view  in  conjunction  with 
available  houses.  Using  a  simple  query,  we  create  demography  themes  for  children  in 
several  age  categories: 

•  Newborn  through  1; 

•  2  through  4; 

•  5  through  6; 

•  7  through  9; 

•  10  through  13; 

•  14  through  18. 

By  combining  these  demography  themes  in  a  view  with  the  available  houses  and  the 
street  themes,  we  create  a  tool  that  allows  customers  to  find  available  houses  in  areas 
matching  their  preferences.  For  example,  when  a  customer  wants  to  find  an  available 
unit  surrounded  by  7-9  year  olds,  s/he  selects  the  appropriately  labeled  theme,  along  with 
the  Available  MFH  and  Street  themes.  The  resulting  graphic,  shown  in  Figure  7-14, 
provides  the  customer  visual  information  that  could  improve  the  assignment  decision  and 
increase  customer  satisfaction.  Without  this  tool,  the  customer  could  only  discover  the 
ages  of  children  in  the  area  of  the  available  houses  by  a  physical  inspection  of  the 
neighborhood,  or  by  viewing  a  printed  text  report. 
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Figure  7-14.  Available  Houses  Superimposed  with  Locations  of  7-9  Year  Old  Children 
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When  a  customer  finds  an  available  house  icon  surrounded  by  children  matching 
his/her  preferences,  then  s/he  may  want  to  know  more  specific  information  about  the 
house.  ArcView  provides  a  tool,  known  as  the  identify  tool,  that  displays  table  data  about 
selected  icons.  For  example,  when  a  service  member  views  the  results  in  Figure  7-14, 
s/he  can  use  the  identify  tool  to  select  a  particular  house  icon.  ArcView  displays  the  table 
data  for  the  selected  house,  which  according  to  the  Identify  Results  window  in  Figure  7- 
15,  is  located  at  240  Ardennes  Circle.  The  window  also  displays  other  information  about 
the  house,  such  as  the  category  and  the  floor  plan  code. 
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D.  SUMMARY 


Users  of  our  HATS  prototype  system  need  to  make  important  decisions  that  affect 
the  quality  of  life  for  service  members  and  their  families.  Just  having  tables  of  data  or 
pages  of  reports  does  not  necessarily  improve  the  decision-making  process.  In  fact,  too 
much  information,  especially  poorly  organized  information,  can  degrade  the  quality  of 
decisions.  We  included  decision  support  tools  in  our  prototype  that  provide  visual 
information  that  contribute  to  knowledge  and  better  decisions. 

Since  we  believe  in  the  adage,  “a  picture  is  worth  a  thousand  words,”  we  chose 
DSTs  that  provide  pictures  for  the  user.  Within  the  DBMS  itself,  users  can  view  up-to- 
date  charts  depicting  occupancy  rates,  and  make  decisions  about  the  housing  inventory. 
By  implementing  a  GIS,  we  were  able  to  capture  the  spatial  aspect  of  the  system.  Our 
GIS  provides  dynamic  pictures  of  houses,  neighborhoods,  and  residents — information 
that  would  otherwise  be  buried  in  tables  of  data. 
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Vin.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  main  purpose  of  this  thesis  was  to  design  and  build  a  relational  database  with 
Web  connectivity  and  decision  support  tools  to  improve  military  housing  utilization 
decisions.  The  ultimate  goal  of  the  system  is  to  improve  the  quality  of  life  for  DoD 
service  members  and  their  families. 

A.  SUMMARY 

The  current  housing  system  used  at  NSAMB,  consisting  of  a  legacy  DBMS  and  a 
series  of  Microsoft  Access  non-relational  tables,  is  incomplete,  unreliable,  and  frustrating 
to  use.  We  employed  a  top-down  systems  engineering  design  approach,  starting  with  a 
detailed  requirements  analysis,  to  determine  requirements  for  our  proposed  system,  the 
Housing  Assignments  and  Terminations  System  (HATS).  We  used  the  Knowledge 
Analysis  of  Tasks  (KAT)  method  to  describe  the  problem  domain,  perform  a  functional 
decomposition,  and  capture  use  cases  to  describe  the  interactions  between  the  users  and 
the  system.  Throughout  the  thesis,  we  referred  to  these  critical  requirements  documents, 
tracing  all  functionality  to  the  use  cases  and  functional  decomposition. 

We  then  used  the  semantic  object  model  (SOM)  as  a  representation  medium  for 
creating  the  logical  database  design.  The  SOM  for  our  system  facilitated  our 
understanding  of  the  attributes  of  the  objects  and  the  relationships  between  houses, 
service  members,  assignments,  and  other  objects  in  our  system.  The  physical  database 
design  that  emerged  from  the  transformation  process  was  normalized  to  avoid  database 
anomalies. 

Migrating  the  operational  data  from  the  current  system  to  our  prototype  was  the 

most  demanding  task,  requiring  not  only  a  thorough  understanding  of  the  business 
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processes  and  the  existing  data  schema,  but  also  scrupulous  attention  to  detail.  A 
verification  process  must  be  established  to  ensure  that  the  migration  provides  valid  data 
in  the  new  system.  Further,  data  managers  should  educate  personnel  concerning  the  best 
ways  to  capture  and  record  data.  In  addition,  they  should  encourage  personnel  to 
implement  data  definition  standards  whenever  possible,  making  future  migrations  more 
reasonable. 

Since  computers  are  ubiquitous  in  today’s  business  offices,  users  expect  effective 
and  pleasing  GUIs  with  their  business  systems.  While  there  are  a  variety  of  powerful 
applications  on  the  market,  acquisition  and  training  costs  are  additional  factors  to 
consider  for  system  implementation.  We  implemented  our  prototype  using  applications 
familiar  to  the  users  and  already  owned  by  the  Housing  Welcome  Center  (HWC).  We 
created  forms,  reports,  and  other  views  for  our  prototype  using  Microsoft  Access.  In 
addition,  we  created  and  published  an  online  housing  application  form,  DD  1746,  using 
Microsoft  Frontpage  and  Internet  Information  Server  (IIS).  By  implementing  ASP  and 
ODBC  technology  in  our  system,  customers  have  direct  input  to  the  database,  eliminating 
the  need  for  the  HWC  to  re-type  housing  applications.  For  our  prototype,  Microsoft’s 
family  of  applications  provides  a  pleasing  and  functional  GUI,  with  acceptable  system 
performance. 

Data  obscurity  degrades  the  ability  of  humans  to  make  decisions.  Our  prototype 
includes  visual  decision  support  tools  (DSTs)  that  improve  the  quality  of  housing 
utilization  decisions  made  by  the  HWC  and  its  customers.  Access  provides  charts  and 
other  visual  tools  that  help  organize  data  into  useful  information.  A  geographic 
information  system  (GIS),  such  as  ESRI’s  ArcView,  captures  and  displays  the  spatial 
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aspect  of  HATS.  By  implementing  DSTs  in  our  prototype,  we  provide  users  with  visual 
information  that  contribute  to  knowledge  and  better  decisions. 

B.  RECOMMENDATIONS 

Based  on  the  results  of  our  research,  we  make  the  following  recommendations: 

•  Before  implementing  any  features  of  the  prototype,  the  HWC  should 
verify  the  quality  of  the  operational  data  in  the  prototype.  Although  we 
performed  an  extensive  data  migration  process,  we  urge  housing  personnel 
more  familiar  with  the  specific  details  of  the  assignment  and  termination 
process  to  verify  data  in  the  prototype.  In  addition,  since  we  took  a 
snapshot  of  the  current  database  to  perform  the  migration,  we  recommend 
updating  the  prototype’s  database  to  reflect  changes  in  the  operational 
data.  For  example,  we  froze  the  current  database  on  18  April  2001.  Since 
then,  the  HWC  has  continued  to  enter  and  modify  data  in  the  current 
system;  however,  these  changes  have  not  been  made  to  the  prototype. 

•  Implement  the  online  housing  application  form  with  connectivity  to  the 
database.  Modify  the  prototype  Web  site  as  needed  and  use  the  Access 
forms  to  allow  customers  to  submit  applications  directly  into  the  HWC 
database.  The  current  system  requires  HWC  counselors  to  re-type 
applications  sent  by  service  members  via  the  Web  application.  The 
prototype  allows  the  counselors  to  simply  review  customer-entered 
applications  and  click  a  button  to  accept  them,  eliminating  redundant  data 
entry. 

•  Replace  the  current  non-relational  Access  database  with  a  relational 
database — such  as  the  prototype  database.  The  HWC  Access  database  is 
not  designed  to  use  the  full  potential  of  a  DBMS.  It  allows  data 
duplication,  restricts  data  integration,  and  fails  to  enforce  business  rules 
and  constraints.  The  protot3q)e’s  relational  database  is  designed  to 
overcome  these  limitations  and  improve  data  quality. 

•  Review  the  policies  and  requirements  to  maintain  an  off-post  rental 
referral  service.  Ten  yeeu's  ago  it  made  sense  to  track  off-post  rental 
property  and  maintain  an  information  system  to  store  and  report  rental 
information  to  service  members.  However,  in  the  Intemet-age,  service 
members  can  view  the  same  information,  if  not  better  information,  via 
non-HWC  Web  sites.  Consider  sharing  information  and  forming 
partnerships  with  off-post  referral  agencies  to  reduce  the  cost  and  effort  to 
provide  a  rental  referral  service.  At  a  minimum,  the  HWC  can  provide 
Internet-enabled  terminals  and  recommended  Web  addresses  to  assist 
service  members  with  off-post  housing  needs. 

•  Improve  the  prototype  and  consider  full  implementation  to  take  advantage 
of  the  decision  support  tools  (DSTs).  Seize  the  opportunity  to  improve  the 
prototype  by  working  with  students  and  faculty  at  the  Naval  Postgraduate 
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School,  as  well  as  analysts  at  TRAC-Monterey.  A  fully  developed  GIS 
can  provide  stimulating  visual  information  to  improve  decisions  made  by 
the  HWC  and  its  customers. 


C.  RECOMMENDATIONS  FOR  FURTHER  DEVELOPMENT 

The  following  are  identified  as  opportunities  for  further  development: 

•  Enhance  the  prototype  by  improving  the  GUI  and  GIS.  Consider 
improving  the  GUI  by  using  more  robust  programming  languages,  such  as 
Java  or  C+.  Design  a  networked  GIS  and  link  the  system  to  additional 
sources  of  data  layers,  such  as  local  law  enforcement  agencies  and 
environmental  organizations. 

•  Implement  the  prototype  in  a  networked  environment.  Determine  the 
most  appropriate  applications  for  implementing  a  “full  up”  network 
system.  Consider  fine-tuning  the  prototype  database  in  Access  for 
increased  performance.  This  could  include  making  the  database  file  an 
executable  file  (with  an  .mde  extension),  or  separating  the  forms,  reports, 
and  macros  from  the  data  files.  Also  consider  implementing  the  database 
using  other  applications,  such  as  Oracle.  Compare  the  alternatives  based 
on  functionality,  network  performance,  training  required,  and  cost. 

•  Determine  if  commercial  off-the-shelf  (COTS)  software  is  a  viable 
alternative  to  implement  the  Assignment  and  Termination  System. 
Consider  the  advantages  and  disadvantages  of  using  COTS  software. 

•  Integrate  the  prototype  with  other  NSAMB  data  systems.  Consider  data 
sharing  initiatives  to  provide  a  logically  unified  database  within  NSAMB. 
By  using  shared  common  data  definitions,  activities  within  NSAMB  can 
share  service  member  information,  reducing  inconsistencies  and 
redundancies.  For  example,  design  an  architecture  to  connect  applications 
used  by  the  installation  vehicle  registration,  childcare  services,  recreation 
activity,  and  the  registrar. 
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APPENDIX  A.  USE  CASES 


Use  Case  Name 

UC5.  Apply  Online 

Participating 

Actor 

Housing  Web  Server  (HWS) 

SM  (through  an  Internet  Browser) 

Summary 

The  SM  visits  the  NSAMB  Housing  Web  site. 
She  fills  out  the  DD  Form  1746,  Application  For 
Assignment  To  Housing,  by  entering  personal 
information  in  the  required  fields  of  the  Web 
page. 

Basic  Course 

Of  Events 

1 .  A  military  service  member  selects  the  “Apply 
For  Housing  Online”  function  on  the  Housing 
Web  page. 

2.  The  HWS  responds  by  presenting  a  blank  DD 
Form  1746,  Application  For  Assignment  To 
Housing,  to  the  SM. 

3.  The  SM  completes  the  required  fields:  type  of 

service  (military  housing  or  referral),  name, 
SSN,  pay  grade,  DOD  component,  address 
(street,  city,  zip),  home  phone,  duty  phone, 
status  of  applicant,  marital  status,  separated 
from  dependents,  request  housing  for,  origin 
organization,  destination  organization, 

effective  rank  date,  active  duty  service 
computation  date,  date  remaining  on  active 
duty,  effective  date  change  in  duty  location, 
report  date,  estimated  family  arrival  date, 
dependents’  names,  dates  of  birth,  sex, 
relationship.  If  the  SM  is  only  asking  for 
referral  information,  then  she  selects  the  type 
of  housing  desired,  amenities  desired,  number 
of  bedrooms,  number  of  bathrooms,  date 
housing  needed,  price  range,  location 
preference,  and  remarks.  After  completing  all 
required  fields,  she  signifies  completion  of  the 
action. 

4.  The  HWS  responds  by  activating  the  CGI 
script  that  emulates  the  “Add  Service  Member 
Record”  function  in  the  system.  The  HWS 
adds  the  record  to  the  HATS  database. 

5.  HATS  sends  an  acknowledgement  to  the 
HWS. 

6.  The  HWS  sends  and  acknowledgement  to  the 
SM  (on  the  Internet). 

Alternative  Paths 

None. 
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Exception  Paths 

In  step  2,  if  the  SM  enters  invalid  data,  or  if  the 
user  leaves  required  fields  blank,  the  Web  server 
responds  by  notifying  the  SM  that  the  input  was 
incorrect  and  asking  her  to  correct  the  DD  Form 
1746. 

Triggers 

The  SM  has  orders  to  the  area  serviced  by  the 
Housing  Office  and  desires  a  future  housing 
assignment. 

Assumptions 

The  Web  server  will  not  accept  a  DD  Form  1746 
if  the  SM  does  not  enter  valid  information.  The 
system  does  not  need  to  inform  the  SM  of 
incorrect  field  entries. 

Preconditions 

The  Web  server  is  operational. 

Postconditions 

The  SM  is  added  to  the  expected  waiting  list. 

Related  Business 
Rules 

NSAMBINST  11101.4:  eligibility  requirements, 
housing  categories,  last  assignment,  and 
dependents. 

Special 

Requirements 

The  HWS  receives  the  acknowledgement  within 
30  seconds.  Depending  on  the  Service  Member’s 
Internet  connection,  she  receives  the 
acknowledgement  not  later  than  60  seconds  after 
clicking  the  “Submit”  button  on  her  browser. 
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Use  Case  Name 
Participating 

Actor _ 

Summary 


Basic  Course 
Of  Events 


Alternative  Paths 


Exception  Paths 


UC 10.  Apply  For  Housing _ 

Housing  Management  Specialist  (HMS) 


The  SM  applies  for  housing  in  person,  or  through 
the  mail.  She  fills  out  the  DD  Form  1746, 
Application  For  Assignment  To  Housing,  and 
gives  a  hard  copy  to  the  HMS. _ 

1.  A  SM  submits  a  completed  DD  Form  1746  to 
the  HMS,  who  in  turn  activates  the  “Add  SM 
Record”  function  of  her  terminal. 

2.  HATS  responds  by  presenting  the  DD  Form 
1746  on  the  display  to  the  HMS. 

3.  The  HMS  completes  the  fields,  by  selecting 
or  entering  the  following:  type  of  service 
(military  housing  or  referral),  name,  SSN,  pay 
grade,  DOD  component,  address  (street,  city, 
zip),  home  phone,  duty  phone,  status  of 
applicant,  marital  status,  separated  from 
dependents,  request  housing  for,  origin 
organization,  destination  organization, 
effective  rank  date,  active  duty  service 
computation  date,  date  remaining  on  active 
duty,  effective  date  change  in  duty  location, 
report  date,  estimated  family  arrival  date, 
dependents’  names,  dates  of  birth,  sex, 
relationship.  If  the  SM  is  only  asking  for 
referral  information,  then  she  selects  the  type 
of  housing  desired,  amenities  desired,  number 
of  bedrooms,  number  of  bathrooms,  date 
housing  needed,  price  range,  location 
preference,  and  remarks.  After  completing  all 
required  fields,  she  signifies  completion  of  the 
form. 

4.  HATS  acknowledges  the  addition  of  a  SM  to 
the  database  and  adds  the  SM  to  the  expected 
waiting  list. 

5.  The  HMS  receives  the  acknowledgement  and 

has  the  option  of  viewing  the  SM  on  the 
waiting  list. _ 

In  step  4,  the  SM  gives  the  HMS  verification  of 
dependents,  orders,  and  departure  from  last 
assignment.  This  alternative  path  puts  the  SM  on 

the  actual  waiting  list. _ 

None. 
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Triggers 

The  SM  has  orders  to  the  area  serviced  by  the 
Housing  Office  and  desires  a  housing  assignment. 

Assumptions 

None. 

Preconditions 

The  SM  wants  government  housing. 

Postconditions 

The  SM  is  added  to  the  waiting  list. 

Related  Business 
Rules 

NSAMBINST  11101.4:  eligibility  requirements, 
housing  categories,  last  assignment,  and 
dependents. 

Special 

Requirements 

The  SM  is  not  added  to  the  database  until  the 
HMS  clicks  on  the  “Submit”  button.  Once  added, 
HATS  sends  an  acknowledgement  within  15 
seconds. 
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Use  Case  Name 

UC 15.  Modify  SM 

Participating 

Actor 

HMS 

Summary 

The  HMS  may  need  to  correct  inaccurate  or 
outdated  SM  information  such  as  number  of 
dependents  or  an  incorrect  SSN. 

Basic  Course 

Of  Events 

1.  The  use  case  begins  when  the  HMS  selects 
the  “Edit  SM  Record”  function  of  HATS. 

2.  HATS  responds  by  prompting  the  HMS  to 
select  the  SM  to  modify. 

3.  The  HMS  selects  the  SM. 

4.  HATS  displays  the  SM’s  record. 

5.  The  HMS  modifies  the  record. 

6.  HATS  displays  the  updated  information. 

Alternative  Paths 

In  step  2,  the  HMS  can  select  the  SM  by  entering 
name,  SSN,  or  address  (if  already  assigned). 

Exception  Paths 

In  step  5,  the  HMS  enters  duplicate  information, 
such  as  SSN.  HATS  alerts  the  HMS  and  prompts 
her  to  enter  valid  information.  The  HMS  enters 
the  correct  information. 

Triggers 

Someone  notifies  the  HMS  that  the  SM 
information  is  not  correct,  prompting  the  HMS  to 
modify  the  SM’s  record. 

Assumptions 

None. 

Preconditions 

The  SM  is  in  the  system. 

Postconditions 

The  SM’s  record  is  updated. 

Related  Business 
Rules 

None. 

Special 

Requirements 

None. 
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Use  Case  Name 


Participating 

Actor 


Summary 


Basic  Course 
Of  Events 


Alternative  Paths 


Exception  Paths 


UC  20.  View  and  Print  Waitins  Lists 


HMS 


The  Housing  Office  constantly  views  the  waiting 
list  to  update  SMs  on  their  place  on  the  list  and 
their  expected  availability  date.  The  HMS’s  also 
print  periodic  lists  to  display  in  the  Housing 
lobby. _ 


1.  The  HMS  activates  the  “View/Print  Waiting 
Lists”  function  of  her  terminal. 

2.  HATS  responds  displaying  all  of  the  different 
waiting  lists  and  prompts  the  HMS  to  select 
one  or  more  list(s)  to  view. 

3.  The  HMS  selects  the  lists. 

4.  HATS  displays  the  lists  on  the  HMS  terminal 
and  prompts  the  HMS  to  print  the  list(s). 

5.  The  HMS  selects  the  option  to  print. 

6.  The  HMS  receives  the  desired  reports  and  I 
makes  her  selection  to  navigate  to  other 
menus. 


In  step  3,  the  HMS  selects  to  print  a  list  without 
viewing  it  first.  The  system  skips  steps  4  and  5. 


None. 


Triggers 


Assumptions 


A  SM  calls  or  visits  the  HMS  to  ask  for  an 
expected  move-in  date.  Every  morning,  an  HMS 

prints  the  lists  to  display  in  the  lobby. _ 

None. 


Preconditions 


Postconditions 


Related  Business 
Rules 


Special 

Requirements 


The  list  is  already  sorted  according  to  the 
business  rules. 


NSAMBINST  1 1 101.4;  freeze  zones  and  waiting 
lists. 


All  sub-functions  end  with  a  menu  to  navigate  to 
the  main  “Manage  Waiting  Lists”  function,  or 
back  to  the  ELATS  main  menu. 
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Use  Case  Name 

UC  25.  Move  SM  to  Actual  Waiting  List 

Participating 

Actor 

HMS 

Summary 

The  SM  gives  the  HMS  verification  of 
dependents,  orders,  and  departure  from  last 
assignment.  With  this  information,  the  HMS  is 
authorized  to  move  the  SM  to  the  actual  waiting 
list. 

Basic  Course 

Of  Events 

1.  The  HMS  selects  the  “Add  SM  to  Actual 
Waiting  List”  function  in  HATS. 

2.  HATS  responds  by  prompting  the  HMS  to 
select  the  SM,  by  SSN  or  by  last  name. 

3.  The  HMS  selects  the  SM. 

4.  HATS  displays  the  SM  and  the  waiting  list 
category  (that  the  SM  is  currently  on  in  the 
expected  waiting  list)  and  prompts  the  user  to 
“Move  SM  to  the  Actual  Waiting  List”. 

5.  The  HMS  signifies  that  she  wants  to  move  the 
SM  to  the  actual  list. 

6.  HATS  sends  an  acknowledgement  to  the 
HMS. 

Alternative  Paths 

In  step  1,  the  HMS  selects  the  SM  from 
the  expected  waiting  list  and  signifies  that  she 
wants  to  move  the  SM  to  the  actual  list,  skipping 
steps  2-5. 

Exception  Paths 

None. 

Triggers 

The  SM  desires  government  housing  and  presents 
the  HMS  with  valid  prerequisite  information. 

Assumptions 

None. 

Preconditions 

The  SM  is  already  on  the  expected  waiting  list. 

Postconditions 

The  system  removes  the  SM  from  the  expected 
list  and  places  her  on  the  actual  waiting  list  (and 
assigns  the  SM  a  control  date). 

Related  Business 
Rules 

NSAMBINST  11101.4:  departure  date 

eligibility,  DEERS,  and  orders. 

Special 

Requirements 

The  HMS  has  the  option  of  viewing  the  new 
waiting  list  for  the  SM.  HATS  sends  an 
acknowledgement  within  30  seconds. 
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Use  Case  Name 

UC30.  Promote  SM 

Participating 

Actor 

HMS 

Summary 

The  SM  receives  a  promotion  since  she  entered 
the  expected  waiting  list,  making  her  eligible  for 
a  higher  category  of  housing.  The  HMS  moves 
the  SM  to  the  new  actual  waiting  list. 

Basic  Course 

Of  Events 

1.  The  HMS  selects  the  “Add  SM  to  Actual 
Waiting  List”  function  in  HATS. 

2.  HATS  responds  by  prompting  the  HMS  to 
select  the  SM,  by  SSN  or  by  last  name. 

3.  The  HMS  selects  the  SM. 

4.  HATS  displays  the  SM  and  the  waiting  list 
category  (that  the  SM  is  currently  on  in  the 
expected  waiting  list)  and  prompts  the  user  to 
“Move  SM  to  the  Actual  Waiting  List”. 

5.  The  HMS  signifies  that  she  wants  to  move  the 
SM  to  the  actual  list. 

6.  HATS  sends  an  acknowledgement  to  the 
HMS. 

Alternative  Paths 

None. 

Exception  Paths 

None. 

Triggers 

The  SM  presents  proof  of  promotion  to  the  HMS 
and  requests  a  move  to  the  new  category  waiting 
list. 

Assumptions 

None. 

Preconditions 

The  SM  is  already  on  an  actual  waiting  list. 

Postconditions 

The  SM  is  on  a  different  actual  waiting  list  that 
matches  her  rank  or  grade.  The  SM  is  no  longer 
on  the  previous  waiting  list. 

Related  Business 
Rules 

NSAMBINST  11101.4:  promotion  status  of 
applicant. 

Special 

Requirements 

The  HMS  has  the  option  of  viewing  the  new 
waiting  list  for  the  SM.  HATS  sends  an 
acknowledgement  within  30  seconds. 
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Use  Case  Name 

UC  35.  Delete  SM  From  Waiting  List 

Participating 

Actor 

HMS 

Summary 

A  SM  is  on  either  the  expected  or  actual  waiting 
list,  but  has  decided  to  live  off  base. 

Basic  Course 

Of  Events 

1.  The  HMS  selects  the  “Delete  SM  from 
Waiting  List”  function  in  HATS. 

2.  HATS  responds  by  prompting  the  HMS  to 
select  the  SM,  by  SSN  or  by  last  name. 

3.  The  HMS  selects  the  SM. 

4.  HATS  displays  the  SM  and  prompts  the  user 
to  “Delete  SM  from  Waiting  List”. 

5.  The  HMS  signifies  that  she  wants  to  delete 
the  SM  from  the  list. 

6.  HATS  sends  an  acknowledgement  to  the 
HMS. 

Alternative  Paths 

In  step  1,  the  HMS  selects  the  SM  from  either  the 
expected  or  actual  waiting  list  and  signifies  that 
she  wants  to  remove  the  SM  from  the  list, 
skipping  steps  2-5. 

Exception  Paths 

None. 

Triggers 

A  SM  requests  that  the  EMS  remove  her  from  the 
waiting  list. 

Assumptions 

None. 

Preconditions 

The  SM  is  on  a  waiting  list. 

Postconditions 

The  SM’s  personal  information  stays  in  the 
system  for  future  assignments. 

Related  Business 
Rules 

NSAMBINST  11101.4:  removing  SM’s  from 
waiting  lists. 

Special 

Requirements 

The  HMS  should  be  able  to  navigate  directly 
from  this  function  to  the  off  base  referral 
function.  HATS  sends  an  acknowledgement 
within  30  seconds. 
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Use  Case  Name 


Participating 

Actor 


Summary 


Basic  Course 
Of  Events 


UC40.  Maintain  Freeze  Zone 


HMS 


Housing  stabilizes  the  position  of  the  top  ten 
percent  of  SMs  on  each  actual  waiting  list  by  not 
placing  new  arrivals  in  the  freeze  zone,  regardless 
of  rank,  duty  assignment,  or  detachment  date. 
They  make  exceptions  for  key  and  essential  SMs, 
based  on  specific  guidance.  When  this  happens. 
Housing  places  these  SMs  at  the  top  of  the  freeze 
zone,  without  displacing  SMs  with  a  housing 
offer. 


1.  The  HMS  activates  the  “Maintain  Freeze 
Zone”  function. 

2.  HATS  displays  all  of  the  different  categories 
of  waiting  lists  and  prompts  the  HMS  to 
select  one  or  more  list(s)  to  maintain. 

3.  The  HMS  selects  the  “Regenerate  Sequence 
Numbers”  function. 

4.  HATS  performs  the  function  and  displays  the 
waiting  list(s)  indicating  the  freeze  zone. 

5.  HATS  sends  an  acknowledgement  to  the 

HMS.  I 


Alternative  Paths  In  step  3,  the  HMS  selects  the  “Change  Freeze 
Zone  Percentage”  function.  HATS  displays  the 
current  percentage  and  prompts  the  HMS  to 
change  it.  The  HMS  enters  the  new  percentage. 

HATS  regenerates  the  Freeze  Zone  based 
on  the  new  percentage  and  sends  an 
acknowledgement  to  the  HMS. 

In  step  3,  the  HMS  places  a  key  SM  at  the 
top  of  the  freeze  zone. 

In  step  4,  the  HMS  has  the  option  to  print 
the  list(s). 


Exception  Paths  None. 


Triggers 


A  key  SM  arrives  and  requests  housing.  Housing 
decides  to  decrease  turbulence  and  increase  the 
freeze  zone.  Housing  decides  to  regenerate 
sequence  numbers  and  update  the  freeze  zone 
(usually  after  several  SMs  have  moved  off  the 
freeze  zone  and  into  housing). 
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Assumptions 

None 

Preconditions 

None 

Postconditions 

If  a  SM  moves  into  housing,  the  system  removes 
her  from  the  freeze  zone  (actual  waiting  list),  but 
does  not  automatically  move  new  SMs  to  fill  her 
position.  If  the  HMS  regenerates  the  sequence 
numbers,  she  creates  a  new  zone  based  on  the 
freeze  zone  percentage. 

Related  Business 
Rules 

NSAMBINST  1 1 101 .4:  freeze  zone. 

Special 

Requirements 

HATS  sends  the  acknowledgement  to  the  HMS  in 
no  more  than  30  seconds. 
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UC  45.  Offer  Housin; 

HMS 


Use  Case  Name 
Participating 

Actor _ 

Summary 


Basic  Course 
Of  Events 


Alternative  Paths 


Exception  Paths 


Triggers 


Assumptions 


The  HMS  notifies  a  SM  that  her  sequence 
number  is  next  on  the  actual  waiting  list.  The 
system  finds  three  houses  matching  the  SM’s 
category  and  the  HMS  offers  the  SM  to  choose 
one  house  to  live  in  (after  visual  inspection). _ 

1.  The  HMS  selects  the  “Make  Housing  Offer” 
fimction. 

2.  HATS  responds  by  prompting  the  HMS  to 
select  the  SM. 

3.  The  HMS  selects  the  SM  by  name  or  SSN. 

4.  HATS  displays  the  SM’s  name,  SSN, 
command,  and  eligibility  category  for 
verification.  HATS  prompts  the  HMS  to 
verify  the  information  and  begin  the  search. 

5.  The  HMS  signifies  that  she  wants  to  begin  the 
search. 

6.  ELATS  responds  by  listing  three  housing 
addresses  that  match  the  search.  HATS 
prompts  the  HMS  to  print  a  copy  of  the  offer. 

7.  The  HDVIS  signifies  that  she  wants  to  print  the 
offer  and  she  makes  a  formal  offer  to  the  SM. 

In  step  2,  the  HMS  can  also  enter  a  specific 
address  if  it  is  a  direct  assignment.  The  HMS 
signifies  that  she  wants  to  directly  assign  a  SM, 

invoking  the  Make  Assignment  use  case. _ 

In  step  4,  the  HMS  notices  incorrect  information 
relating  to  the  SM.  She  makes  the  corrections 

and  continues  with  the  offer. _ 

The  SM  moves  to  the  top  of  the  actual  waiting  list 
and  the  HMS  meets  with  the  SM  to  make  an 

offer. _ _ _ _ 

The  HMS  only  offers  available  houses,  as 
reported  by  the  HFS. 


Preconditions 

The  SM  has  the  next  sequence  number  on  the 
actual  waiting  list. 

Postconditions 

The  system  list  three  houses  to  offer  the  SM. 

Related  Business 
Rules 

NSAMBINST  11101.4:  offering  housing--If 
housing  cannot  contact  the  SM  with  the  next 
sequence  number,  the  HMS  may  offer  MFH  to 
the  next  SM  on  the  list.  The  HMS  can  skip  the 
SM  as  long  as  she  cannot  be  reached,  and 
eventually,  the  SM  can  be  placed  at  the  bottom  of 
the  waiting  list. 

Special 

Requirements 

HATS  responds  to  the  HMS  within  30  seconds  of 
the  search  request. 
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Use  Case  Name 


Participating 

Actor 


Summary 


Basic  Course 
Of  Events 


Alternative  Paths 


Exception  Paths 


Triggers 


Assumptions 


UC  50.  Make  Assignment 


HMS 


The  SM  chooses  to  occupy  one  of  the  houses 
offered  by  the  HMS,  who  makes  the  official 
assignment  (matching  the  SM  with  a  housing 
address). _ 


1.  A  SM  accepts  an  offer  (after  selection  or 
direct  assignment)  and  the  HMS  selects  the 
“Assign  Housing”  function  in  HATS. 

2.  HATS  prompts  the  HMS  to  select  the  SM  (by 
name  or  SSN). 

3.  The  HMS  enters  name  or  SSN. 

4.  HATS  displays  the  SM’s  name,  rank,  SSN 
and  the  addresses  offered  to  the  SM.  HATS 
prompts  the  HMS  to  verify  the  information 
and  proceed. 

5.  The  HMS  signifies  that  she  wants  to  proceed 
with  the  assignment. 

6.  HATS  creates  the  assignment  and  prints  a 
Housing  Acceptance  Letter. 


In  step  2,  the  HMS  searches  for  the  address 
chosen  by  the  SM  to  occupy.  HATS  displays  the 
address  and  the  name,  rank,  and  SSN  of  the  SM 
offered  the  house. 


In  step  2,  the  HMS  enters  the  wrong  address  and 
the  system  responds  with  an  existing  assignment 
or  with  no  offer.  HATS  displays  an  error 
message  and  the  HMS  enters  another  address. 


The  SM  tells  the  HMS  that  she  accepts  an  offer 
for  housing,  causing  the  HMS  specify  an 
assignment  in  the  system. 


None 


Preconditions  The  SM  accepted  a  housing  offer. 


Postconditions  HATS  makes  an  assignment  relating  the  SM  and 
the  chosen  housing  address. 


Related  Business  NSAMBINST  11101.4:  assignment  and 

Rules  inspection. 

Special  The  HMS  can  only  enter  addresses  already  in  the 

Requirements  system. 
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Use  Case  Name 

Participating 

Actor 


UC  55.  Terminate  Assignment 
Initiated  by  HMS 


Communicates  with  Facilities  Supervisor  (HFS) 

Summary 

SMs  frequently  receive  orders  to  move  to  other 
duty  stations.  Once  a  SM  has  orders,  she 
completes  an  “Intent  to  Vacate”  letter  and 
informs  the  HMS  of  the  specific  dates. 
Eventually,  the  SM  moves  and  terminates  the 
housing  assignment. 

Basic  Course  1 .  The  HMS  selects  the  “Terminate  Housing” 
Of  Events  function  of  HATS . 


2.  HATS  responds  by  prompting  the  HMS  for 
the  SM  name  or  SSN. 

3.  The  HMS  chooses  the  departing  SM. 

4.  HATS  displays  the  SM’s  name,  SSN,  and  unit 
address  for  verification  and  prompts  the  HMS 
to  enter  the  expected  vacancy  date. 

5.  The  HMS  enters  the  date. 

6.  HATS  displays  an  “Intent  to  Vacate”  letter, 
displaying  the  SM’s  name  and  SSN,  MFH 
address,  a  tentative  pre-termination  inspection 
date,  and  the  expected  vacancy  date  (which 
will  become  the  final  inspection  date).  HATS 
prompts  the  HMS  to  verify  the  information, 
change  dates  if  necessary,  and  print  the 
“Intent  to  Vacate”  letter. 

7.  The  HMS  verifies  (and  changes  dates  if 
necessary)  and  signifies  that  she  wants  to 
print  the  letter. 

8.  After  the  final  inspection  (on  the  expected 
vacancy  date),  the  SM  returns  to  the  HMS 
with  the  clearing  sheet  (and  the  inspector’s 
signature).  The  HMS  navigates  the 
“Terminate  Housing”  menu  to  select  the 
“Print  Termination  Letter”  function. 

9.  HATS  prompts  the  HMS  to  enter  the  SM’s 
name  or  SSN. 

10.  The  HMS  enters  the  name. 

11.  HATS  displays  the  SM  and  address 
information. 

12.  The  HMS  signifies  that  she  wants  to  print  the 
termination  letter  and  she  terminates  the 
housing  assignment. 

13.  HATS  prints  a  termination  letter  for  the  SM 
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and  changes  the  status  of  the  MFH  to 
unavailable. 


Alternative  Paths 

In  step  2,  the  HMS  enters  the  soon-to-be- 
terminated  housing  address.  In  steps  9  and  10, 
the  HMS  enters  the  address. 

Exception  Paths 

In  step  4,  the  HMS  enters  a  past  date,  indicating 
that  the  SM  has  already  moved.  HATS  responds 
by  sending  an  error  message  and  prompting  the 
HMS  to  enter  another  date. 

Triggers 

A  SM  has  orders  and  requests  that  the  HMS 
terminate  her  housing  assignment. 

Assumptions 

The  expected  vacancy  date  is  less  than  one  year 
from  the  current  date. 

Preconditions 

The  SM  is  assigned  housing. 

Postconditions 

The  SM  is  not  assigned  housing  and  is  eligible  for 
Basic  Allowance  for  Housing. 

Related  Business 
Rules 

NSAMBINST  1 1 101 .4:  terminations, 

inspections,  and  outprocessing. 

Special 

None. 

Requirements 


Use  Case  Name 

UC  60.  Prepare  CRL 

Participating 

Actor 

HMS 

Summary 

An  incoming  SM  wants  information  on  off-base 
housing.  The  SM  gives  the  HMS  search  criteria 
for  desired  living  arrangements.  The  HMS  enters 
the  information  into  HATS  and  prints  a  Customer 
Referral  List  for  the  SM. 

Basic  Course 

Of  Events 

1.  The  HMS  selects  the  “Prepare  Customer 
Referral  List”  function  of  HATS. 

2.  HATS  responds  by  prompting  the  HMS  to 
enter  the  SM’s  name  or  SSN. 

3.  The  HMS  enters  the  name  or  SSN. 

4.  HATS  prompts  the  HMS  to  select  search 
criteria  (price,  size,  location,  smoking,  pets, 
number  of  matches  to  display,  and  so  on). 

5.  The  HMS  indicates  the  SM’s  preferences. 

6.  HATS  displays  the  results  and  prompts  the 
HMS  to  print  the  CRL. 

7.  The  HMS  signifies  that  she  wishes  to  print  the 
CRL. 

8.  HATS  prints  the  CRL. 

Alternative  Paths 

None. 

Exception  Paths 

In  step  6,  the  HMS  enters  the  SM’s  preferences 
and  HATS  does  not  find  any  matching  referrals. 
HATS  sends  the  HMS  an  error  message  and 
prompts  her  to  enter  less  restrictive  preferences. 

Triggers 

A  SM  asks  the  HMS  to  find  off-base  housing 
matching  her  preferences. 

Assumptions 

The  SM  can  already  be  assigned  MFH.  This  is  a 
one-time  transaction  and  the  HMS  does  not  keep 
a  record  of  the  details  of  each  referral.  The  SM 
asks  for  a  one-time  referral.  She  can  alwa)^  ask 
for  a  new  one  in  the  future,  but  the  HMS  has  to 
enter  new  search  criteria — ^the  system  does  not 
save  CRLs  or  search  criteria. 

Ill 


Preconditions 

HATS  already  knows  the  SM  and  the  private 
property. 

Postconditions 

None. 

Related  Business 
Rules 

None. 

Special 

Requirements 

None. 
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Use  Case  Name 


Participating 

Actor 


Summary 


Basic  Course 
Of  Events 


Alternative  Paths 


Triggers 


Assumptions 


Preconditions 


Postconditions 


Related  Business 
Rules 


Special 

Requirements 


UC  65.  Add  or  Edit  MFH 


HMS 


Occasionally,  the  HMS  needs  to  edit  the 
description  of  MFH  to  reflect  upgrades  or 
modifications.  In  the  event  of  new  construction, 
this  is  the  use  case  used  to  add  the  address  to  the 
inventory. 


1.  This  use  case  begins  when  the  HMS  selects 
the  “Add  or  Modify  Unit  Details”  function  of 
HATS 

2.  HATS  responds  by  prompting  the  HMS  for 
the  address  of  the  unit  to  modify. 

3.  The  HMS  enters  the  address. 

4.  HATS  displays  a  description  of  the  MFH. 

5.  The  HMS  changes  any  desired  field  or  fields 
and  signifies  that  she  is  finished  with  the 
editing. 

6.  HATS  accepts  the  changes  and  displays  the 
address  with  the  most  current  information. 


In  step  3,  the  HMS  signifies  that  she  wishes  to 
add  a  new  address.  HATS  displays  blank  fields 
for  the  HMS  to  enter  information  describing  the 
quarters.  The  HMS  signifies  that  she  is  finished 
and  wishes  to  exit  the  screen.  HATS 
acknowledges  the  addition  of  a  new  address  to 
the  system. _ 


None. 


The  HMS  wishes  to  change  information  about  an 
address  or  add  a  new  address  to  the  system. _ 


None. 


If  the  HMS  wishes  to  edit  an  address,  the  address 
must  already  exist.  If  the  HMS  wishes  to  add  a 
new  address,  the  address  cannot  already  exist  in 
HATS. 


None. 


None. 


None. 


113 


UC  70.  Add  or  Edit  Private  Proper 

HMS 


Use  Case  Name 
Participating 

Actor _ 

Summary 


Basic  Course 
Of  Events 


iL 


Details  about  off  base  rental  property  change 
almost  daily.  The  PIMS  needs  to  add  new  rental 
property  to  the  system  and  change  descriptions 

and  terms  to  existing  properties. _ 

1.  The  use  case  begins  when  the  HMS  selects 
the  “Manage  Referral  Information”  function 


ofHATS. 


2.  HATS  prompts  the  HMS  to  select  the 
property  to  edit. 

3.  The  HMS  selects  the  property. 

4.  HATS  displays  the  property  information. 

5.  The  HMS  edits  all  desired  fields  and  signifies 
that  she  is  finished. 

6.  HATS  acknowledges  the  editing  and  displays 


an  updated  view  of  the  property. 


Alternative  Paths 

In  step  2,  the  HMS  selects  the  owner  or  property 
manager.  HATS  displays  the  addresses  of  the 
properties  owned  or  managed  and  prompts  the 
HMS  to  select  one.  The  HMS  selects  an  address. 

In  step  2,  the  HMS  signifies  that  she  wishes  to 
add  a  new  rental  property  to  the  system.  HATS 
responds  by  asking  the  HMS  to  enter  information 
describing  the  property.  The  HMS  enters  the 
information.  HATS  acknowledges  the  addition  of 
a  new  property. 

Exception  Paths 

hi  Steps,  the  EGMS  enters  a  new  property  owner  or 
manager  who  does  not  exist  in  the  system.  HATS 
alerts  the  HMS  that  she  must  also  enter 
information  about  the  owner  or  manager. 

Triggers 

The  HMS  has  to  change  information  about  rental 
property  due  to  new  rental  terms  or  characteristics 
of  the  property.  An  owner  or  manager  lists  new 
property  with  the  HMS. 

Assumptions 

None. 

Preconditions 

If  the  HMS  wishes  to  edit  property  information, 
the  address  must  already  exist  in  the  system.  If 
the  HMS  wishes  to  add  the  property  to  the 
system,  it  cannot  already  exist. 

Postconditions 

None. 

Related  Business 
Rules 

NAVINST  1101.04:  Off  base  referrals  and  rules 
governing  rental  property. 

Special 

Requirements 

None. 
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Use  Case  Name 

UC75.  Delete  Address 

Participating 

Actor 

HMS 

Summary 

For  one  reason  or  another,  the  HMS  needs  to 
remove  either  government  or  privately-owned 
property.  For  example,  the  owner  of  an  off  base 
property  decides  to  sell  and  no  longer  offer  it  for 
rent.  Or  in  the  case  of  the  government  quarters, 
the  base  sells  the  property  to  another  entity. 

Basic  Course 

Of  Events 

1.  The  use  case  begins  when  the  HMS  selects 
the  “Delete  an  Address”  function  of  HATS. 

2.  HATS  prompts  the  HMS  to  enter  the  address. 

3.  The  HMS  enters  the  address. 

4.  HATS  displays  the  address  details  and 
prompts  the  user  to  verify  the  deletion. 

5.  The  HMS  verifies  the  deletion. 

6.  HATS  deletes  the  record  of  the  address  and 
returns  to  the  “Manage  Housing  Inventory” 
menu. 

Alternative  Paths 

In  step  2,  the  HMS  signifies  that  she  wishes  to 
delete  an  off  base  address.  In  step  6,  HATS 
displays  the  “Manage  Referral  Information” 
menu. 

Exception  Paths 

None. 

Triggers 

The  HMS  needs  to  delete  the  record  of  either  a 
government  or  a  privately-owned  property. 

Assumptions 

None. 

Preconditions 

The  address  must  already  exist. 

Postconditions 

HATS  deletes  the  record  of  the  address.  Records 
of  historical  assignments  are  not  deleted. 

Related  Business 
Rules 

None. 

Special 

Requirements 

None. 
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Use  Case  Name  UC  80.  Add  or  Edit  Owner  or  Manager 


Participating 

Actor 

HMS 

Summary 

The  HMS  adds  or  edits  information  about  an 
owner  or  property  manager.  This  can  happen  due 
to  a  sale,  or  when  a  new  manager  takes  over  the 
property. 

Basic  Course 

Of  Events 

1.  The  use  case  begins  when  the  HMS  selects 
the  “View  Referral  Details”  function  of 
HATS. 

2.  HATS  prompts  the  HMS  to  enter  the  owner 
or  manager’s  information. 

3.  The  HMS  enters  the  information,  signifying 
whether  she’s  an  owner  or  manager,  and 
selecting  the  related  property  (if  known  at  the 
time). 

4.  HATS  acknowledges  the  addition. 

Alternative  Paths 

In  step  2,  the  HMS  signifies  that  she  wishes  to 
edit  owner  or  manager  information.  HATS 
prompts  her  to  select  the  person  to  edit.  The 
HMS  edits  the  information  and  signifies  that  she 
is  finished.  HATS  acknowledges  the  editing. 

None. 

Triggers 

An  owner  or  manager  informs  the  HMS  that  there 
has  been  a  change  in  ownership  or  management. 

Assumptions 

None. 

Preconditions 

In  order  to  edit  the  owner  or  manager,  she  must 
already  exist  in  the  system. 

Postconditions 

The  owner  or  manager  is  in  the  system.  If  the 
HMS  just  edits  the  owner  or  manager,  then  the 
new  information  is  saved. 

Related  Business 
Rules 

None. 

Special 

Requirements 

None. 
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Use  Case  Name 

UC  85.  Change  Availability 

Participating 

Actor 

Facilities  Supervisor  (EFS) 

Summary 

When  a  specific  house  is  unavailable  to  SMs,  the 
HFS  has  to  provide  a  date  when  she  thinks  the 
unit  will  be  ready  for  occupancy.  Once  move-out 
or  other  maintenance  is  complete,  the  HFS 
notifies  the  system  that  the  MFH  is  fit  for  a  new 
occupant. 

Basic  Course 

Of  Events 

1.  The  HFS  selects  the  “Manage  Availability  of 
MFH”  function  within  HATS. 

2.  HATS  prompts  the  HFS  to  enter  the  MFH 
address. 

3.  The  HFS  enters  the  address. 

4.  HATS  displays  the  address  information  on  the 
HFS  terminal  and  prompts  the  HFS  to  enter  or 
change  the  expected  availability  date,  or  make 
the  address  available. 

5.  The  HFS  enters  the  expected  date,  or  signifies 
that  she  wants  to  make  the  address  available, 
and  signifies  that  she  wants  to  proceed. 

6.  HATS  displays  the  current  availability 
information. 

Alternative  Paths 

None. 

Exception  Paths 

In  step  5,  the  HFS  enters  a  future  date  for  the 
“actual  available  date”  field.  HATS  alerts  the 
HFS  that  it  only  accepts  past  or  current  dates  in 
that  field.  HATS  returns  to  the  field  and  prompts 
the  HFS  to  enter  another  date. 

Triggers 

Termination  of  MFH,  maintenance  factors  affect 
the  expected  availability  date,  or  the  unit  becomes 
available. 

Assumptions 

The  HFS  enters  expected  and  actual  availability 
dates  within  a  few  days  of  the  discovery. 

Preconditions 

The  MFH  is  in  the  system  and  unoccupied. 

Postconditions 

HATS  knows  the  expected  available  date  or  the 
unit  is  available. 

Related  Business 
Rules 

None. 
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Special 

Requirements 


The  HFS  does  this  function  remotely.  This  may 
require  a  CGI  script  or  other  interface  to  change 
the  availability  of  housing.  (HATS  updates  the 
availability  status  in  the  database.) _ 
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Use  Case  Name 

UC  90.  View  and  Print  Reports 

Participating 

Actor 

HMS 

HFS 

Summary 

There  are  over  20  reports  that  users  request  from 
the  system  on  any  given  day.  The  HMS  or  HFS 
can  use  the  “Queries  &  Reports”  function  of 
HATS  or  she  can  use  menus  in  the  other 
functions  to  view  and  print  reports. 

Basic  Course 

Of  Events 

1 .  The  use  case  begins  when  the  actor  selects  the 
“Queries  &  Reports”  function  of  HATS. 

2.  HATS  responds  by  prompting  the  actor  to 
select  a  specific  report  to  view  or  print. 

3.  The  actor  selects  the  desired  report. 

4.  HATS  displays  the  report  and  prompts  the 
actor  to  print  the  report. 

5.  The  actor  signifies  that  she  wants  to  print  the 
report. 

6.  HATS  prints  the  report. 

Alternative  Paths 

In  step  1,  the  actor  can  also  select  the  view  or 
print  report  function  from  within  the  other 
functions,  such  as  “Assignments  & 

Terminations”. 

In  step  3,  the  actor  can  print  the  report  without 
viewing  it. 

In  step  6,  HATS  returns  to  the  report  view  and 
prompts  the  actor  to  exit  the  report  and  return  to 
the  “Reports”  main  menu.  The  actor  signifies 
that  she  wants  to  exit  the  menu.  HATS  returns  to 
the  “Reports”  main  menu. 

Exception  Paths 

None. 

Triggers 

The  actor  needs  to  print  a  daily,  weekly,  monthly, 
quarterly,  annual,  or  other  report. 

Assumptions 

None. 

Preconditions 

The  report  must  already  exist. 

Postconditions 

None. 

Related  Business 
Rules 

NSAMBINST  11101.4:  reporting  procedures  and 
waiting  list  reports. 

Special 

Requirements 


Internet  users  can  also  view  reports  by  using  the 
Web  menu  to  select  the  desired  reports.  The 
interaction  is  the  same  as  this  use  case,  except 
there  are  fewer  reports  available  online.  In  either 
case,  HATS  displays  the  selected  reports  within 
30  seconds  of  the  user’s  request. _ 
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Use  Case  Name 

UC  95.  Manage  Accounts 

Participating 

Actor 

HDBA  (Housing  Database  Administrator) 

Summary 

Employees  come  and  go,  get  promoted,  or  change 
positions  at  the  Housing  Office,  requiring 
changes  to  user  access  to  the  system. 

Basic  Course 

1.  The  use  case  begins  when  the  HDBA  selects 

Of  Events 

the  “Manage  User  Access”  function  of  HATS. 

2.  HATS  responds  by  prompting  the  HDBA  to 
select  a  user. 

3.  The  HDBA  selects  the  user. 

4.  HATS  displays  the  user’s  access  permissions. 

5.  The  HDBA  changes  the  permissions  as 
desired. 

6.  HATS  displays  the  new  permissions. 

Alternative  Paths 

In  step  2,  HATS  asks  if  the  HDBA  wants  to  “Add 
a  New  User”.  The  HDBA  replies  that  she  wants 
to  add  a  new  user.  HATS  displays  an  input  form 
for  the  HDBA  to  enter  the  user’s  information. 

In  step  5,  the  RDBA  signifies  that  she  wants  to 
delete  the  user  from  the  system.  HATS  prompts 
her  for  a  confirmation.  The  HDBA  confirms  the 
deletion.  HATS  acknowledges  the  action. 

Exception  Paths 

In  step  2,  the  HDBA  adds  a  new  user,  but  she 
enters  a  duplicate  SSN.  HATS  alerts  the  HDBA 
and  prompts  her  to  enter  valid  data.  The  HDBA 
enters  a  valid  SSN. 

Triggers 

A  new  employee  needs  access  to  the  system  or  a 
former  employee  no  longer  needs  access  to  the 
system. 

Assumptions 

None. 

Preconditions 

If  the  HDBA  wants  to  modify  or  delete  a  user, 
she  must  already  exist  in  the  system.  If  the 
HDBA  wants  to  add  a  user,  she  cannot  already  be 
in  the  system. 

Postconditions 

If  the  HDBA  adds  a  new  user,  the  system  creates 
a  new  user  record.  If  the  HDBA  deletes  a  user, 
the  user  no  longer  has  access.  If  the  HDBA 
modifies  user  information,  such  as  access,  the 
user  has  the  updated  permissions. 

Related  Business 
Rules 

None. 

Use  Case  Name 

UC  100.  Maintain  Database 

Participating 

Actor 

HDBA 

Summary 

The  HDBA  needs  to  maintain  the  database  in  the 
system  occasionally.  She  may  need  to  change 
forms,  reports,  or  other  internal  files  in  order  to 
maintain  the  system.  Also,  Housing  does  not 
want  another  user  inadvertently  changing  the 
database  stmcture  and  corrupting  the  system. 

Basic  Course 

Of  Events 

1.  The  use  case  begins  when  the  HDBA  selects 
the  “Manage  Database”  function  of  HATS. 

2.  HATS  responds  by  prompting  the  HDBA  to 
select  the  forms,  tables,  or  reports  to  modify. 

3.  The  HDBA  selects  the  item  to  modify. 

4.  HATS  displays  the  item. 

5.  The  HDBA  performs  maintenance  and  closes 
the  screen. 

Alternative  Paths 

None. 

Exception  Paths 

None. 

Triggers 

The  HDBA  needs  to  change  a  form  or  report  in 
the  system. 

Assumptions 

None. 

Preconditions 

None. 

Postconditions 

None. 

Related  Business 
Rules 

None. 

Special 

Requirements 

This  is  not  an  essential  use  case.  Because  we 
already  know  that  we’re  using  MS  Access,  we 
don’t  need  to  design  a  fictional  interface  to  the 
data. 
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Use  Case  Name 

UC 105.  Authenticate  User 

Participating 

HMS 

Actor 

HFS 

Summary 

All  users  who  request  entry  to  the  system  must 
prove  they  are  who  they  say  they  are 
(authentication).  This  applies  to  users  inside 
Housing  as  well  as  outside.  Who  the  users  are 
determines  what  they  have  access  to 
(authorization). 

Basic  Course 

1.  The  use  case  begins  when  the  user  enters  a 

Of  Events 

user  identification  and  password. 

2.  The  system  responds  by  checking  the 
combination  of  user  identification  and 
password  against  the  recorded  list  of  valid 
users. 

3.  The  system  responds  by  notifying  the  user 
that  the  user  identification  and  password  are 
valid  and  allows  the  user  access  to  the  system. 

Alternative  Paths 

None 

Exception  Paths 

In  step  2,  if  the  user  identification  and  password 
combination  is  not  valid,  the  system  responds  by 
notifying  the  user  that  the  combination  was 
invalid  and  asks  the  user  to  try  again.  If  the  user 
tries  three  times  unsuccessfully,  the  system 
responds  by  disallowing  the  user  and  marking  as 
suspended  the  user  record  of  any  and  all  user 
identifications  tried.  In  step  2,  if  the  user 
identification  that  is  tried  is  in  suspended  mode, 
the  system  responds  by  notifying  the  user  that  this 
identification  has  been  suspended  and  the  user 
must  contact  the  system  administrator. 

Triggers 

The  user  requires  access  to  the  system. 

Assumptions 

If  the  system  resides  on  a  network  system,  the 
user  already  has  access  to  the  network. 

Preconditions 

The  system  is  operational. 

Postconditions 

The  validated  user  is  allowed  access  to  the 
system. 

Related  Business 
Rules 

None. 
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APPENDIX  B.  HATS  SEMANTIC  OBJECT  MODEL 


SERVICEMEMBER  Object 

•  Key  is  SSN; 

•  SM  may  currently  occupy  at  most  one  MFHUNIT  (currently  assigned  to); 

•  SM  may  be  enrolled  in  only  one  WAITING  LIST; 

•  SM  may  not  have  FAMILY  MEMBERS  (in  the  case  of  a  referral),  but  he  may 
have  many; 

•  SM  is  not  required  to  have  a  current  housing  assignment,  but  he  may  have  at  most 
one. 

MFHUNIT  Object 

•  Key  is  UnitED; 

•  MFH  may  have  at  most  one  SM; 

•  MFH  is  on  one-and-only-one  BASE; 

•  MFH  is  in  one-and-only-one  NEIGHBORHOOD; 

•  MFH  has  one-and-only-one  FLOOR  PLAN; 

•  MFH  is  described  by  one-and-only-one  HOUSING  CATEGORY ; 

•  MFH  has  0-to-many  APPLIANCES; 

•  MFH  can  have  only  one  ASSIGNMENT  at  any  point; 


WAITINGLIST  Object 

•  Key  is  WaitingListTitle  (BASE  +  HOUSING  CATEGORY); 

•  WAITING  LIST  may  have  0-to-many  SERVICE  MEMBERS  waiting  for 
housing. 

ASSIGNMENT  Object 

•  Key  is  Assignment®  (SERVICE  MEMBER  SSN  +  MFH  UNIT  Address  + 
AssignmentDate); 

•  ASSIGNMENT  can  be  made  by  one-and-only-one  HMS. 


FAMILYMEMBER  Object 

•  Key  is  FamilyMember®  (SM  SSN  +  RelationCode); 
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FLOORPLAN  Object 


•  Key  is  FloorPlanCode; 

•  A  FLOOR  PLAN  may  be  used  in  many  different  MFH  UNITS; 
HOUSINGCATEGORY  Object 

•  Key  is  Designation; 

•  A  HOUSING  CATEGORY  can  apply  to  many  MFH  UNITS ; 

•  A  HOUSING  CATEGORY  can  have  at  most  one  WAITING  LIST. 

APPLIANCE  Object 

•  Key  is  AppliancelD; 

•  An  APPLIANCE  may  be  in  only  one  MFH; 

BASE  Object 

•  Key  is  BaseName; 

•  A  BASE  may  have  one-to-many  NEIGHBORHOODS; 

•  A  BASE  may  have  one-to-many  MFH  UNITS. 

NEIGHBORHOOD  Object 

•  Key  is  NeighborhoodName; 

•  A  NEIGHBORHOOD  may  be  on  one-and-only-one  BASE; 

•  A  NEIGHBORHOOD  may  contain  one-to-many  MFH  UNITS . 

PRIVATE  RENTAL  PROPERTY  Object 

•  Key  is  Address; 

•  A  PRIVATE  RENTAL  PROPERTY  can  only  have  one  OWNER; 
OWNER  Object 

•  Key  is  OwnerCode; 

•  An  OWNER  may  have  one-to-many  PRIVATE  RENTAL  PROPERTIES. 
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SYSTEM  USER  Object 

•  Key  is  UserlD; 

•  A  SYSTEM  USER  may  also  be  an  HMS  (subtype); 

•  A  SYSTEM  USER  may  also  be  an  HFS  (subtype); 

•  A  SYSTEM  USER  may  also  be  a  SYSTEM  ADMINISTRATOR  (subtype). 

HMS  Object 

•  An  HMS  is  a  subtype  of  SYSTEM  USER  with  the  same  key  of  UserlD; 

•  An  HMS  may  create  many  ASSIGNMENTS; 

•  An  HMS  has  one-and-only-one  access  level. 

HFS  Object 

•  An  HFS  is  a  subtype  of  SYSTEM  USER  with  the  same  key  of  UserlD; 

•  An  HFS  has  one-and-only-one  access  level. 

SYSTEM  ADMISTRATOR  Object 

•  A  SYSTEM  ADMINISTRATOR  is  a  subtype  of  SYSTEM  USER  with  the  same 
key  of  UserlD; 

•  A  SYSTEM  ADMINISTRATOR  has  one-and-only-one  access  level. 
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APPENDIX  C.  HATS  RELATIONAL  MODEL 


SERVICEMEMBER  (SSN,  LastName,  FirstName,  MI,  Paygrade,  BranchOfService, 
DateOfRank,  PRD,  NumberOfFamilyMembers,  Command,  Priority,  HomePhone, 
WorkPhone,  SpouseWorkPhone,  Email,  BedRoomsRequested,  BedRoomsAuthorized, 
DeferUntilDate,  ControlDate,  Pets,  Weapons,  Medical,  Remarks,  Designation_FK, 
BaseName_FK) 

WATTSTATUS  ISSN  FK,  Designation  FK.  BaseName  FK.  SequenceNumber, 
InFreezeZone) 

MFHUNIT  (UnitlD.  StreetNumber,  ApartmentNumber,  StreetName, 
NeighborhoodName_FK,  Occupied,  M-Code,  IssuedToFacilitiesDate, 
COMCompletionDate,  DateAvailable,  RetumDate,  YearBuilt,  FACNum,  InService, 
Remarks,  FloorPlanCode_FK,  NeighborhoodName_FK) 

WATTINGLIST  (Designation  FK,  BaseName  FK,  PercentInFreezeZone ) 

ASSIGNMENT  (UnitID  FK.  SSN  FK.  DateAssigned.  VacatedDate, 
FinallnspectionDate,  ClearancelnspectionDate,  Pre-inspectionDate,  DateRenewed, 
COMCost,  UserID_FK) 

FAMILYMEMBER  (SSN  FK  ,  FirstName.  Birthdate.  MI,  LastName,  Relation) 

FLOORPLAN  (FloorPlanCode.  FPDescription,  Designation_FK,  NumberOfBedrooms, 
NumberOfBathrooms,  Floors,  SqFt,  Attic,  Firepl,  Basemt,  Carpet,  Garage,  Hardfl, 
Remarks) 

APPLIANCE  (AppliancelD,  TypeOfAppliance,  SerialNumber,  Manufacturer, 
InstallDate,  Warranty,  UnitID_FK) 

BASE  (BaseName.  Description) 

ZIPCODE  (Zip.  City,  State) 

NEIGHBORHOOD  (NeighborhoodName.  BaseName_FK,  Zip_FK) 

HOUSINGCATEGORY  (Designation.  BaseName  FK.  NumberOfBedrooms) 

PRIVATERENTALPROPERTY  (PropertvID.  StreetNumber,  ApartmentNumber, 
StreetName,  Zip_FK,  ComplexName,  DateOfAvailability,  Available,  FloorPlanType, 
SqFt,  Rent,  PetsAllowed,  NumberOfBedrooms,  NumberOfBath,  Attic,  Firepl,  Basemt, 
Carpet,  Garage,  Hardfl,  Remarks,  OwnerCode_FK) 

OWNER  (OwnerCode.  PointOfContact,  Street,  Zip_FK,  Phone,  Fax,  Remarks) 
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SYSTEMUSER  (UserlD,  UserPassword,  LastName,  FirstName,  MI) 
HMS  CUserlD  FK.  AccessLevel) 

HFS  (UserlD  FK.  AccessLevel) 

SYSTEMADMINISTRATOR  (UserlD  FK.  AccessLevel) 
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APPENDIX  D.  REPORTS 


Actual  Wait  List 

Cat£^t?jy 

2JBQMC 

Control  Date 

La^t  J>S2me 

fintt 

Grade 

Defer  Date 

AYALA 

CARLOS 

E3 

12rt1flaDD 

BAIL  LIE  UL 
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Ei 

2/9i2m 

WILSON 
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E2 
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2JOLM 

Contr^  Date 

La^tl^me 

Fir^t 

Grade 

Defer  Date 
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TRANKLIN 

03 
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02 

\2/2iamu 
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4/&2EE1 
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03 

Category 

2JOOMC 
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03 
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03 
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La^t  I^me 
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Grade 

Defer  Date 

3CDOT11 
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E5 

Category 
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Lastf^tne 

First 

Grade 

Defer  Date 

snsCTDO 
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CARL 

05 

sn/ziDi 

answcco 
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CHEONG 

Oi 

^2/2^f2mn 

B  ULGAKDV 

IGOR 

Oi 

12JGDQCni 

BARRY 

ROBERT 

Oi 

Zf2aw^ 

SCHMIDT 
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Oi 

5/15J2ID1 
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ROGERD 

Oi 

Siifidsy,  Nsy  27^,  3CD1  7  cfB 


Figure  D- 1 .  Wait  List  Report 
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Housing  Staiistics 


Total  Units 

^Occu^£d 

U  Vacant 

Occupancy  % 

Total 

2.2S6 

1.893 

3r3 

535 

TotalUnits 

^Occupied 

U  Vacant 

Occupancy  % 

POM 

68 

61 

7 

89.7 

CMC 

1.SST 

1.3t8 

239 

8i5 

Total 

i.ess 

I.UIS 

2i6 

8S.1 

Total  y>222? 

UOccu^ed 

#  V^^ant 

Occupancy  % 

LaMssa 

S97 

i73 

12  i 

IS  2 

}^PS 

u 

11 

3 

785 

Total 

611 

48i 

127 

792 

Figure  D-2.  Housing  Statistics  Report 
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Figure  D-3.  Coast  Guard  Report 
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M{^ors^  Report 


Nei^barhood  FITCH 


Address 

Apt. 

Street 

First  Marne 

219 

ARDENNES  CIRCLE 

ROLANDO 

227 

ARDENNES  CIRCLE 

KATHLEEN 

2ii 

ARDENNES  CIRCLE 

lAJARREN 

25D 

ARDENNES  CIRCLE 

JORGE 

251 

ARDENNES  CIRCLE 

KIP 

258 

ARDENNES  CIRCLE 

ALEX 

355 

ARDENNKCIRCLE 

ANDY 

XI2 

HATTEN  ROAD 

ADONIS 

315 

HATTEN  ROAD 

MARK 

218 

METZ  ROAD 

DAVID 

22i 

UETZROAD 

ASIU 

325 

UETZROAD 

JONATHAN 

338 

UETZROAD 

STEVEN 

215 

REMAGEN  ROAD 

EOAIARD 

2D3 

ALEUTIAN  ROAD 

CRAC 

211 

ALEUTIAN  ROAD 

PATRCK 

156 

CORRBGIDOR  RDA 

STEVEN 

157 

CORRBGIOOR  ROA 

KEVIN 

158 

CORRBGIDOR  ROA 

CARLOS 

ISi 
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STEVEN 
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GILLESP  IE  LANE 

JOSEPH 

27. 2001 
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2 
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N 

OLSON 

Oi 

3 
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Oi 
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A 
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03 

1 

N 
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03 

5 

A 
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03 

2 

N 
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03 

5 

A 
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02 

2 
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2 

X 
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03 
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2 

A 
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Ei 
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A 
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E2 

2 

A 
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1 
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E5 
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N 

TYSON 

E5 

1 

A 

SASS 

E5 

2 

A 

WESTBERRY 

E5 

1 

N 

SULLIVAN 

04 

3 

N 

Figure  D-4.  Mayors’  Report 
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Vacate  Report  for  December  2000 
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Figure  D-5.  Vacate  Report 
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Occupant  Report 

I  borhood  FIT  CH 


Street  # 

Street 

Apt  UnitU 

Last  Name 

First 

Fa^^ade 

Dependents 

300 

AACHEN  ROAD 

31259 

tAJILLIAUS 

CLIFTON 

03 

i 

301 

AACHEN  ROAD 

X91 

ANDERSON 

TIM 

03 

3 

302 

AACHEN  ROAD 

X92 

TAYID  R 

TARL 

Oi 

S 

X3 

AACHEN  ROAD 

X90 

VBGTER 

HENRY 

02 

3 

30i 

AACHEN  ROAD 

X9i 

GORAK 

MARK 

03 

i 

xs 

AACHEN  ROAD 

X95 

RUDOF 

ROBERT 

02 

2 

X6 

AACHEN  ROAD 

X9? 

DOLLDFF 

KATHERINE 

03 

2 

X7 

MCHEN  ROAD 

X95 

DEFINE 

CRAIG 

03 

5 

X8 

AACHEN  ROAD 

X99 

KUe  ISTA 

THBDDORE 

03 

2 

X9 

AACHEN  ROAD 

xm 

DUGONE 

THBDDO  RE 

03 

i 

310 

AACHEN  ROAD 

X01 

DIMUICK 

MATTHBAI 

03 

3 

311 

AACHEN  ROAD 

3302 

SPENCE 

EDUUAR 

03 

3 

312 

AACHEN  ROAD 

XOi 

JOHNSON 

STEVEN 

03 

i 

313 

AACHEN  ROAD 

XD6 

KENNEDY 

RICHARD 

02 

2 

3U 

AACHEN  ROAD 

XOT 

MCLEAN 

CHARLES 

03 

2 

315 

AACHEN  ROAD 

X1D 

DAVIS 

CHRETOP 

03 

i 

316 

AACHEN  ROAD 

X12 

HARRIS 

BENJAMIN 

03 

3 

315 

AACHEN  ROAD 

XU 

COOMBS 

JO  HN 

03 

i 

XI 

ALGERIA  ROAD 

2619 

MUHAMMAD 

ANGELA 

03 

3 

X3 

ALGERIA  ROAD 

X21 

PARSONS 

DARREN 

03 

3 

Xi 

ALGERIA  ROAD 

X22 

SORENSON 

ANDRBiru 

03 

3 

XS 

ALGERIA  ROAD 

XX 

CHI-HOON 

KiU 

03 

2 

X7 

ALGERIA  ROAD 

X2i 

PATERSON 

RYAN 

03 

1 

210 

ALGERIA  ROAD 

XX 

CEL  IK 

GUNER 

02 

1 

XD 

ARDENNES  CIRCLE 

X27 

SCHEIN 

ARI 

03 

1 

XI 

ARDENNES  CIRCLE 

XX 

MING 

MEL 

CWU3 

2 

X3 

ARDENNES  CIRCLE 

X29 

ROSS 

JAMES 

03 

3 

Msy  7T,  :W1 

Pe2el<f62 

Figure  D-6.  Occupant  Report 
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Noti-eligible  Report 


Lastl^ame 

First 

MI 

SVC 

PRD 

Address 

CAN 

YUKSEL 

02 

X 

sisonooo 

1277  SPRUANCE  ROAD 

KALLOCH 

AARON 

S 

OS 

A 

&S0/2000 

1051  HALSEY  DRIVE 

KALLOCH 

AARON 

E 

OS 

A 

osmooo 

S31 BBERGN  DRIVE 

MEWES 

TIMOTHY 

J 

OS 

F 

5/21/2001 

SlI  HATTmROAD 

CAREIER 

KEVIN 

J 

04 

N 

3/S0/2001 

12  MERVNE  STREET 

DCNAEUE 

MICHAEL 

C 

OS 

A 

5/24/2001 

202  SamROAD 

MASON 

FREDERICK 

J 

05 

A 

l/SQ/2000 

4S4  LEWIS  ROAD 

CONFER 

JASON 

R 

E6 

M 

5/20/2001 

401  MDDENROAD 

ELEA2BR 

PATRICIA 

A 

E5 

F 

025/2000 

S06  BRITTANY  ROAD 

MURPHF 

DANIEL 

E 

OS 

N 

5/26/2000 

S32  D3ERGN DRIVE 

ROOKE 

JEFFREY 

T 

ES 

M 

5/17/2001 

mNOmiEAROAD 

MAGUIRS 

GREG 

M 

04 

N 

osonooo 

2SSANZIOROAD 

BYERS 

MICHAEL 

R 

E5 

N 

5/1/2001 

102  SOLOMCNROAD 

lAmAMAm 

DANIEL 

L 

OS 

N 

5/2S/2001 

534  CMICHELSONRO 

KORENOSK! 

JAMES 

J 

avi 

A 

5/17/2001 

SOO  ARLONCOURTRO 

MALLOY 

ARREN 

L 

E6 

M 

4/12/2001 

SIOKALBOFNROAD 

RAUSCH 

JEFFERY 

S 

E5 

A 

4/sonooi 

416  KALBORN  ROAD 

GONZALEZ 

FRANK 

R 

E5 

5  '  s  -  -■  r  1 

F 

5/20n001 

125  CORREGIDORROA 

McxSsy.Msy2S.  XOl 


Figure  D-7.  Non-eligible  Report 
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Utiiiziation  Report 


#  Occupied 

MH:?!d 

MAvmlcble 

Utilizatii:^  I^te 

1922 

IS 

229 

05J3% 

Ju\^2(}00 

19D1 

73 

252 

85.i% 

1927 

es 

23i 

865% 

SepteiTher  20(^ 

1929 

$5 

232 

85.7% 

October  2000 

1917 

6d 

2i1 

85.1% 

NovejTTber  2000 

1913 

67 

245 

855% 

Dccerrher  2000 

19  ID 

65 

250 

855% 

Jamiary  2001 

191$ 

80 

231 

855% 

Fcbmory  2001 

1925 

75 

225 

855% 

MQrch2001 

1928 

71 

227 

855% 

April 2 001 

1902 

7a 

25i 

85.4% 

Mqy2001 

1893 

68 

265 

855% 

Figure  D-8.  Utilization  Report 
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School  ChUdreu  (by  Base) 


\s. 

First  Marne 

Last 

FElakon 

Birth  Date 

A^e 

RYLAND 

DARLING 

s 

5J29/1997 

i 

PHILLIP 

PEITSO 

s 

5/19^997 

i 

MMB  ERLY 

RUEOA 

D 

S/1S/1997 

i 

HALE/ 

UUOFFORD 

D 

Sn/1997 

i 

ALEXANDRA 

BERRY 

D 

ifl7fl997 

i 

CONOR 

ARMSTRONG 

S 

4/r/1997 

i 

ALLISON 

NASH 

D 

ifi/1997 

i 

MEGHAN 

HOGAN 

D 

3/17/1997 

i 

N  CO  LAOS 

PAVLOUDIS 

S 

3/16/1997 

MARIAM 

ALQETAMI 

D 

3/13/1997 

i 

NCHOLAS 

PONCE 

S 

36/1997 

i 

VICTO  RIA 

MORRIS 

D 

2^3/1997 

i 

em  11/ 

bra  isle  Ifer 

D 

2/17/1997 

i 

ASHLEY 

PAYNE 

D 

2/li/1997 

i 

NATHAN 

PECK 

S 

2/1D/1907 

i 

JYLE 

SANDERS 

S 

26/1997 

i 

EMILY 

PETERS 

D 

26/1997 

i 

SAMANTHA 

PRCE 

D 

26/1997 

i 

N  CO  LAS 

GRANDJEAN 

S 

ICI/1997 

i 

KATRINA 

MULLER 

D 

1/1S/1997 

i 

DILLON 

O'BRIEN 

S 

1/9/1997 

i 

UlA 

STREZI 

D 

16/1997 

i 

JAIME 

FOSTER 

D 

16/1997 

i 

TIMOTHY 

DB/LIN 

S 

16/1997 

i 

CHIEN 

YEN 

S 

16/1997 

i 

Moiiisy.Msy:^  XOl 


Figure  D-9.  School  Children  Report 


139 


Asstgnme^Histofy 

Base  LM 

VmtU  1 

370  A  BSSGmDmyE 

Date  Assigned  Date  Vacated 

SSN 

last  HatTie 

iX25m96 

i7i^2^35 

OCASIO 

SQsyisee  9/17/1995 

522-1 9-76  i1 

UmKEFIELD 

IOC  1/1 995  6J25/33DD 

i75-7Mni5 

MCCABE 

UmtU  2 

370  3  SSESlNDSiyS 

Date  Assigned  Date  Vacated 

SSH 

lastNattte 

1/1Q/199*  3/27/1996 

23CK]i^i6 

PROTACD 

&2EV1996  1/1  i/1995 

225^^01 

irUHITESCARVER 

3Qirt995  6/3D/1999 

397-7  4-7115 

ZANDER 

7/6/1999  ^2/Z^nm} 

21&52-E)515 

ZAUUISLAK 

UnitU  3 

m  C  BSSaiNDEiyf 

Date  ^1^572^^  Date  Vacated 

SSH 

last  Nanie 

12Q2/1993  515/1995 

15r-i8-1i73 

MARINO 

1C  i/1996  iJ2/1995 

SS7-iS-i395 

JERAULD 

6C3/1995  5/iClll] 

S35^[3-3079 

SHEA 

Unit^  4 

370  D  BEI^m DRIVE 

Date  Assigned  Date  Vacated 

SSH 

last  Name 

S/7/1 995  7/3D/1996 

219-71^6531 

JONES 

5C9/1996  3C5/I999 

i72-7  W51S 

DELGADO 

6/1/1999 

i85-9S-1533 

PECK 

UnitU  5 

370  E  BEEGE\WF3'E 

Date  Assigned  Date  Vacated 

SSN 

last  Name 

650/199  i  iaC/1996 

1SS-52-15S3 

FREE 

6/9/1995  iJO/1906 

□63-6D-7612 

WEST 

Suxd^.  Msr  27. 20D1 


Figure  D- 1 0.  Assignment  History  Report 
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